From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Re: [PATCH] [RFC] Credit2 scheduler prototype Date: Fri, 29 Jan 2010 00:56:55 +0000 Message-ID: References: <4B4DF825.1090100@eu.citrix.com> <940bcfd21001281527j257e9389w8ff8cb8e311aecc9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <940bcfd21001281527j257e9389w8ff8cb8e311aecc9@mail.gmail.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: Dulloor Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org Since it's an assertion, I assume you ran it with debug=3Dy? I'm definitely changing some assumptions with this, so it's not a surprise that some assertions trigger. I'm working on a modified version based on the discussion we had here; I'll post a patch (tested with debug=3Dy) when I'm done. -George On Thu, Jan 28, 2010 at 11:27 PM, Dulloor wrote: > 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" wrot= e: >>> >>> >>>> >>>> [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 pat= ch >>> 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 lock= s? >>> (Just an extra thought). >>> >> >> Hmm.... can't see anything wrong with it. =A0It would make the whole loc= king >> 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 >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >