From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Re: [PATCH] [RFC] Credit2 scheduler prototype Date: Wed, 13 Jan 2010 16:43:17 +0000 Message-ID: <4B4DF825.1090100@eu.citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed 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: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > 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). > Hmm.... can't see anything wrong with it. It would make the whole locking discipline thing a lot simpler. It would, AFAICT, remove the need for private per-runqueue locks, which make it a lot harder to avoid deadlock without these sorts of strange tricks. :-) I'll think about it, and probably give it a spin to see how it works out. -George