From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: Tim Deegan <Tim.Deegan@eu.citrix.com>,
George Dunlap <dunlapg@umich.edu>,
Zhigang Wang <zhigang.x.wang@oracle.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Cpu pools discussion
Date: Thu, 30 Jul 2009 14:51:54 +0200 [thread overview]
Message-ID: <4A71976A.8040704@ts.fujitsu.com> (raw)
In-Reply-To: <C69718AB.10ED3%keir.fraser@eu.citrix.com>
Keir Fraser wrote:
> On 30/07/2009 06:46, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
>
>>> Another alternative might be to create a 'hypervisor thread', either
>>> dynamically, or a per-cpu worker thread, and do the work in that. Of course
>>> that has its own complexities and these threads would also have their own
>>> interactions with cpu pools to keep them pinned on the appropriate physical
>>> cpu. I don't know whether this would really work out simpler.
>> There should be an easy solution for this: What you are suggesting here sounds
>> like a "hypervisor domain" similar to the the idle domain, but with high
>> priority and normally all vcpus blocked.
>>
>> The interactions of this domain with cpupools would be the same as for the
>> idle domain.
>>
>> I think this approach could be attractive, but the question is if the pros
>> outweigh the cons. OTOH such a domain could open interesting opportunities.
>
> I think especially if cpupools are added into the mix then this becomes more
> attractive than the current approach. The other alternative is to modify the
> two existing problematic callers to work okay from softirq context (or not
> need continue_hypercall_on_cpu() at all, which might be possible at least in
> the case of CPU hotplug). I would be undecided between these two just now --
> it depends on how easily those two callers can be fixed up.
I'll try to set up a patch to add a hypervisor domain. Regarding all the
problems I got with switching cpus between pools (avoid running on the cpu to
be switched etc.) this solution could make life much easier.
And George would be happy to see all the borrow cpu stuff vanish :-)
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: ts.fujitsu.com
D-81739 Muenchen Company details: ts.fujitsu.com/imprint.html
next prev parent reply other threads:[~2009-07-30 12:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-27 15:20 Cpu pools discussion George Dunlap
2009-07-27 15:50 ` Keir Fraser
2009-07-28 0:41 ` Zhigang Wang
2009-07-28 9:19 ` Tim Deegan
2009-07-28 10:15 ` Juergen Gross
2009-07-28 12:50 ` George Dunlap
2009-07-28 13:07 ` Tim Deegan
2009-07-28 13:24 ` Juergen Gross
2009-07-28 13:31 ` Tim Deegan
2009-07-28 13:39 ` Juergen Gross
2009-07-28 13:47 ` George Dunlap
2009-07-28 13:57 ` Juergen Gross
2009-07-28 15:29 ` Dan Magenheimer
2009-07-28 15:49 ` Keir Fraser
2009-07-28 16:26 ` George Dunlap
2009-07-29 0:29 ` Zhigang Wang
2009-07-29 5:47 ` Juergen Gross
2009-07-28 13:41 ` George Dunlap
2009-07-28 13:55 ` Keir Fraser
2009-07-29 6:14 ` Juergen Gross
2009-07-29 7:39 ` Keir Fraser
2009-07-29 8:52 ` Juergen Gross
2009-07-29 9:35 ` Keir Fraser
2009-07-29 11:06 ` Juergen Gross
2009-07-29 12:28 ` Keir Fraser
2009-07-29 12:33 ` Juergen Gross
2009-07-29 13:00 ` Keir Fraser
2009-07-30 5:46 ` Juergen Gross
2009-07-30 8:30 ` Keir Fraser
2009-07-30 8:58 ` Juergen Gross
2009-07-30 12:51 ` Juergen Gross [this message]
2009-07-30 13:18 ` Keir Fraser
2009-07-31 5:25 ` Juergen Gross
2009-07-28 5:40 ` Juergen Gross
2009-07-28 9:09 ` Keir Fraser
2009-07-28 10:19 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A71976A.8040704@ts.fujitsu.com \
--to=juergen.gross@ts.fujitsu.com \
--cc=Tim.Deegan@eu.citrix.com \
--cc=dunlapg@umich.edu \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
--cc=zhigang.x.wang@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.