WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] deadlock in the credit2

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Eunbyung Park <silverbottlep@xxxxxxxxx>
Subject: Re: [Xen-devel] deadlock in the credit2
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Fri, 14 Oct 2011 13:11:01 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 14 Oct 2011 05:11:39 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=7sMs+4xRmuxSnrA3u5SNhlknafJhT/yKS0ISrtVqvu8=; b=kCRnKNtp0xa9vfHk/V7AO7WB9EpMxKKtVBIlMZubwYOCWk2gmgif3cY4R1z5tiyfQ7 /V5+5YfGwjKixCCrw9a885/JZXAhfwWaVptZT5+XD2Px2/WQqyDr/meM+rAdRwoWqTZi 2azXetUc3c63S8Xw76yI9XrqJjdTWcjLZyI9E=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAFLBxZZfH88_-+4i_j8dz3qTh+grxc2wUxuh0e6f7jiV4t9zzQ@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcyKalaK4cbIPVc/mECCJItmqaFuUg==
Thread-topic: [Xen-devel] deadlock in the credit2
User-agent: Microsoft-Entourage/12.30.0.110427
On 14/10/2011 12:47, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> wrote:

> 2011/10/14 Eunbyung Park <silverbottlep@xxxxxxxxx>:
>> IMHO, it seems to be deadlock when changing dom0's weight in credit2
>> scheduler.
>> 
>> when the sched_adjust() in schedule.c is called, it grabs the
>> schedule_lock after pausing all of the vcpus
>> 
>> and then, csched_dom_cntl in sched_credit2.c, it also grab the
>> schedule_lock by using vcpu_schedule_lock_irq().
>> 
>> In the credit2, all of the percpu schedule_lock points out same runqueue
>> lock if they belong to same runqueue.
>> 
>> Eventually, all of vcpu are paused except for itself running the code,
>> and it try to grab schedule_lock that was grabbed by itself.
>> 
>> Am I right? If I was wrong, please tell me my misunderstanding.
> 
> Hmm, I think you may have discovered the source of a bug that people
> have been reporting but I haven't had time to look into yet.
> 
> Keir, I think that lock in schedule.c around SCHED(adjust) must be
> wrong.  By the time we grab that lock, grabbing it will be completely
> pointless.  What are we going to be racing against?  In any case, the
> actual scheduler should be responsible for grabbing locks; there's no
> reason that the scheduler can't grab whatever lock it needs inside
> that function.  I haven't done a deep analysis, but my initial
> instinct is to just get rid of it.  What do you think?

Fine by me. The synchronisation in that function looks pretty fragile. It's
probably outdated too.

 -- Keir

>> if ( d == current->domain )
>> vcpu_schedule_lock_irq(current);
>> 
>> It was very hard to understan for me..:) What does it exactly mean?
> 
> You're asking what "current" means?  "current" is a macro that always
> resolves to the vcpu which is running on the current processor.
> 
> sched_adjust() seems to be trying to avoid scheduling races in general
> by pausing all vcpus before calling the per-scheduler function.  But
> if a VM is calling the op on itself, the vcpu making the hypercall
> can't pause itself.  So in that case (current->domain == d) will be
> true, so sched_adjust() grab the schedule lock of that vm instead.
> 
> But really all that locking should be handled in the scheduler
> function, not by the generic code.  It knows best what needs to be
> locked when.
> 
>  -George



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>