[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PROPOSAL] Doing work in idle-vcpu context


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Mon, 19 Apr 2010 07:00:07 +0200
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 18 Apr 2010 22:01:06 -0700
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=KwA3Bi+wWtP/32fiNIEM7TqXgS82BXnvieK4TsYjN0DIbDRjhczmdXlq eBbP8iKygBsw5ybfNCEhWK5WEgJM71jbhPoXkBtNKsUPCdbwqpPwaBNaw dqlSLVylASFr4qEm2EyOtntiPAjkpRbbjy2fpcUnXecN5BgmfHqtNcUPD Q8JtkYzpM1A4kOGnnk6PJRonuQIu4fNOkE/g2eipuqpq1HSCttUB2eLSz eSU2b2bMFbMZ88vvGPB8GcSDl9XkQ;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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 enter
> 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 architecturally
> 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 vcpu
> context. Rather than introducing the whole kthread concept into Xen, one
> possibility would be to schedule this work on the idle vcpus -- effectively
> promoting idle vcpus to a more general kind of 'Xen worker vcpu' whose job
> 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 mechanism
> be to implement do you think?
> 
> More generally: what do people think of this idea?

Sounds a little bit like my original proposal for the change of c_h_o_c():
Introduce a "hypervisor domain" for stuff like this.
I still think, this would be cleaner. The hypervisor vcpus would run with
high priority and they could block without rising major problems.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.