From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dulloor Subject: Re: [PROPOSAL] Doing work in idle-vcpu context Date: Tue, 20 Apr 2010 02:50:18 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: George Dunlap , "Jiang, Yunhong" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Mon, Apr 19, 2010 at 6:52 AM, Keir Fraser wr= ote: > So I've now implemented this at the tip of xen-unstable staging tree. Exc= ept > that I retasked the concept of 'tasklets' to implement this, rather than > introducing a whole new abstraction like Linux workqueues. Yeah, this looks better. > > Thanks to Dulloor for initial changes to the credit scheduler. I should h= ave > acknowledged you in the changeset comment too: sorry about that. :-( No problem :) > > George: let me know if the scheduler changes in c/s 21197 look okay. George might be able to comment better, but two things : 1. Should we not set (ret.time) to some timeslice (rather than -1) when we BOOST the idle_vcpu (for csched and csched2). 2. Is it fine to use a simple list_empty in checking if the tasklet_queue is empty for a cpu, with other cpus possibly accessing the list too. > > =A0Thanks, > =A0Keir > > On 16/04/2010 19:05, "Keir Fraser" wrote: > >> George, Yunhong, and others, >> >> So, it seems that runing stop_machine_run(), and now >> continue_hypercall_on_cpu(), in softirq context is a bit of a problem. >> Because the softirq can stop the currently-running vcpu from being >> descheduled we can end up with subtle deadlocks. For example, with s_m_r= () >> we try to rendezvous all cpus in softirq context -- we can have CPU A en= ter >> the softirq interrupting VCPU X, meanwhile VCPU Y on CPU B is spinning >> trying to pause VCPU X. Hence CPU B doesn't get into softirq, and so CPU= A >> never leaves it, and we have deadlock. >> >> There are various possible solutions to this, but one of the architectur= ally >> neatest would be to run the s_m_r() and c_h_o_c() work in a >> 'Linux-workqueue' type of environment -- i.e., in a proper non-guest vcp= u >> context. Rather than introducing the whole kthread concept into Xen, one >> possibility would be to schedule this work on the idle vcpus -- effectiv= ely >> promoting idle vcpus to a more general kind of 'Xen worker vcpu' whose j= ob >> can include running the idle loop. >> >> One bit of mechanism this would require is the ability to bump the idle = vcpu >> priority up - preferably to 'max' priority forcing it to run next until = we >> return it to idle/lowest priority. George: how hard would such a mechani= sm >> be to implement do you think? >> >> More generally: what do people think of this idea? >> >> =A0Thanks, >> =A0Keir >> > > >