From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: scheduler independent forced vcpu selection Date: Thu, 19 May 2005 10:05:59 -0500 Message-ID: <20050519150559.GO7305@us.ibm.com> References: <20050517204832.GH7305@us.ibm.com> <428B30BC.8070602@cl.cam.ac.uk> <20050518223744.GL7305@us.ibm.com> <428C93B5.6060001@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <428C93B5.6060001@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stephan Diestelhorst Cc: Stephan Diestelhorst , Ryan Harper , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Stephan Diestelhorst [2005-05-19 09:04]: > Ryan Harper schrieb: > > * Stephan Diestelhorst [2005-05-18 09:04]: > > > >>>I'm working on a new hypercall, do_confer, which allows the directed > >>>yielding of a vcpu to another vcpu. It is mainly used when a vcpu fails > >>>to acquire a spinlock, yielding to the lock holder instead of spinning. I > >>>ported the ppc64 spinlock implementation for the i386 linux portion. In > >>>implementing the hypercall, I've been trying to figure out how to get > >>>the scheduler (I've only played with bvt) to run the vcpu passed in the > >>>hypercall (after some validation) but I've run into various bad state > >>>situations (do_softirq pending != 0 assert, '!active_ac_timer(timer)' > >>>failed , and __task_on_runqueue(prev) failed) which tells me I > >>>don't fully understand all of the book-keeping that is needed. Has > >>>anyone thought about how to do this with either BVT or the new EDF > >>>scheduler? > > > > > > After some thought, domain_wake(), followed by > > raise_softirq(SCHEDULE_SOFTIRQ) does what I want and removes the huge > > mess I was making in __enter_scheduler(). > > Are you waking up the domain that holds the lock? Then you would rely on > the scheduler to give the woken domain a high "priority" (whatever this > means for the current scheduler) and should start that domain > immediatelly, right? I noticed your comments in sched_sedf.c about domain waking. * 3. Unconservative (i.e. incorrect) * -to boost the performance of I/O dependent domains it would be possible * to put the domain into the runnable queue immediately, and let it run * for the remainder of the slice of the current period * (or even worse: allocate a new full slice for the domain) * -either behaviour can lead to missed deadlines in other domains as * opposed to approaches 1,2a,2b Giving the remainder of the current slice to the domain we are waking *sounds* like what I wanted, but you are concerned that it causes missed deadlines. Could you elaborate when we would have such a case? If we are only running in the remaining timeslice (which would expire before the next deadline) then why would such behaviour lead to missing deadlines? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com