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] Re: [PATCH] [RFC] Credit2 scheduler prototype

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] [RFC] Credit2 scheduler prototype
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 13 Jan 2010 16:36:54 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 13 Jan 2010 08:37:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a1001130805p2e53f92bibf99a058aa21b43a@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: AcqUaizXGJOKsU7HTBCfuUdSXy8VDwABHB6S
Thread-topic: [Xen-devel] Re: [PATCH] [RFC] Credit2 scheduler prototype
User-agent: Microsoft-Entourage/12.23.0.091001
On 13/01/2010 16:05, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> wrote:

> [NB that the current global lock will eventually be replaced with
> per-runqueue locks.]
> 
> In particular, one of the races without the first flag looks like this
> (brackets indicate physical cpu):
> [0] lock cpu0 schedule lock
> [0] lock credit2 runqueue lock
> [0] Take vX off runqueue; vX->processor == 1
> [0] unlock credit2 runqueue lock
> [1] vcpu_wake(vX) lock cpu1 schedule lock
> [1] finds vX->running false, adds it to the runqueue
> [1] unlock cpu1 schedule_lock

Actually, hang on. Doesn't this issue, and the one that your second patch
addresses, go away if we change the schedule_lock granularity to match
runqueue granularity? That would seem pretty sensible, and could be
implemented with a schedule_lock(cpu) scheduler hook, returning a
spinlock_t*, and a some easy scheduler code changes.

If we do that, do you then even need separate private per-runqueue locks?
(Just an extra thought).

 -- Keir



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