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: Wed, 29 Jul 2009 08:14:05 +0200 [thread overview]
Message-ID: <4A6FE8AD.3020308@ts.fujitsu.com> (raw)
In-Reply-To: <C694C1D6.10B73%keir.fraser@eu.citrix.com>
Keir Fraser wrote:
> On 28/07/2009 14:41, "George Dunlap" <dunlapg@umich.edu> wrote:
>
>> As Juergen says, for people who don't use the feature, it shouldn't
>> have any real effect. The patch is pretty straightforward, except for
>> the "continue_hypercall_on_cpu()" bit.
>
> Just pulled up the patch. Actually cpupool_borrow_cpu() does not seem to
> lock down the cpu-pool-vcpu relationship while continue_hypercall_on_cpu()
> is running. In particular, it is clear that it does nothing if the vcpu is
> already part of the pool that the domain is running in. But then what if the
> cpu is removed from the pool during the borrow_cpu()/return_cpu() critical
> region? It hardly inspires confidence.
I checked the use cases.
All calls leading to cpupool_borrow_cpu() are done under the domctl lock.
The same applies to all cpupool operations.
I can add an explicit check not to unassign borrowed cpus, if you like.
>
> Another thing I noted is that sched_tick_suspend/resume are pointlessly
> changed to take a cpu parameter, which is smp_processor_id(). I swear at the
> screen whenever I see people trying to slip that kind of nonsense in. It
Sorry, this seems to be an artefact of an earlier version of my changes.
I'll remove this one...
> makes it look like the functions can operate on an arbitrary cpu when in
> fact I'll wager they cannot (and I doubt the author of such changes has
> checked). It's a nasty nasty interface change.
I'm pretty sure they could indeed work on any cpu. At least I tried to use
them on other cpus, but I ran into other problems leading to the current
solution not requiring the cpu parameter any more.
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-29 6:14 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 [this message]
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
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=4A6FE8AD.3020308@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.