From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dulloor Subject: Re: Re: [PATCH] [RFC] Credit2 scheduler prototype Date: Thu, 28 Jan 2010 18:27:44 -0500 Message-ID: <940bcfd21001281527j257e9389w8ff8cb8e311aecc9@mail.gmail.com> References: <4B4DF825.1090100@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4B4DF825.1090100@eu.citrix.com> 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" , Keir Fraser List-Id: xen-devel@lists.xenproject.org George, With your patches and sched=3Dcredit2, xen crashes on a failed assertion : (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) Assertion '_spin_is_locked(&(*({ unsigned long __ptr; __asm__ ("" : "= =3Dr"(* (XEN) Is this version supposed to work (or is it just some reference code) ? thanks dulloor On Wed, Jan 13, 2010 at 11:43 AM, George Dunlap wrote: > 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 =3D=3D 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 patc= h >> 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. =A0It would make the whole lock= ing > discipline thing a lot simpler. =A0It 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 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >