| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PROPOSAL] Doing work in idle-vcpu context
|
To: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [PROPOSAL] Doing work in idle-vcpu context |
|
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 |
|
Dkim-signature: |
v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1271653103; x=1303189103; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4BCBE357.7080104@xxxxxxxxxxxxxx>|Date:=20 Mon,=2019=20Apr=202010=2007:00:07=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx> |CC:=20"Jiang,=20Yunhong"=20<yunhong.jiang@xxxxxxxxx>,=20 =0D=0A=20George=20Dunlap=20<George.Dunlap@xxxxxxxxxxxxx>, =0D=0A=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@lis ts.xensource.com>|Subject:=20Re:=20[Xen-devel]=20[PROPOSA L]=20Doing=20work=20in=20idle-vcpu=20context|References: =20<C7EE6596.1192F%keir.fraser@xxxxxxxxxxxxx> |In-Reply-To:=20<C7EE6596.1192F%keir.fraser@xxxxxxxxxxxxx >|Content-Transfer-Encoding:=207bit; bh=UEkYCefMrmbDYqik2bfpRsS8foYo3ZHKkqlKudUCiqo=; b=U705ESltu4eOubZLAjAZBCWxLVnzlICRtswGMN32DlbLBevgIoiB+4Jg Y0TnEqb5idZ6O6/QUQf7Xuay07/d7iLgYweDvIB0PeaUTfEVU7CQVhKjC XIn/KqzFyxjlb3McsZCW5FfYMc+B/4ZPK+jzS1Bo7Ev6fSMTWuZyc+2mm ayp0IJaJ+WhCMgplWmHZ0qA67DeKob0bxbjcPCJ21O/ZzUn9zXjFuCrrx vnP4UidztvqlojJMnOnH+arUsK4Fh; |
|
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; |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C7EE6596.1192F%keir.fraser@xxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Organization: |
Fujitsu Technology Solutions |
|
References: |
<C7EE6596.1192F%keir.fraser@xxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla-Thunderbird 2.0.0.24 (X11/20100329) |
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
|
|
|
| |
|
Home