From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: [PATCH] [RFC] Credit2 scheduler prototype Date: Wed, 13 Jan 2010 16:36:54 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 13/01/2010 16:05, "George Dunlap" 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