Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1225456
| From | Dario Faggioli <dario.faggioli@citrix.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy |
| Date | 2015-09-15 19:20 +0200 |
| Message-ID | <q923D-2S5-5@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <pZCBr-4hc-11@gated-at.bofh.it> <q3zYm-4sz-25@gated-at.bofh.it> <q4eRP-4a6-3@gated-at.bofh.it> <q4h3j-7tc-1@gated-at.bofh.it> <q4hmG-7PP-13@gated-at.bofh.it> |
| Organization | Citrix Inc. |
[Multipart message — attachments visible in raw view] - view raw
On Wed, 2015-09-02 at 16:30 +0200, Juergen Gross wrote: > On 09/02/2015 04:08 PM, Boris Ostrovsky wrote: > > On 09/02/2015 07:58 AM, Juergen Gross wrote: > >> On 08/31/2015 06:12 PM, Boris Ostrovsky wrote: > >>> If set_cpu_sibling_map()'s has_mp is false, wouldn't we effectively have > >>> both of your patches? > >> > >> Hmm, sort of. > >> > >> OTOH this would it make hard to make use of some of the topology > >> information in case of e.g. pinned vcpus (as George pointed out). > > > > > > I didn't mean to just set has_mp to zero unconditionally (for Xen, or > > any other, guest). We'd need to have some logic as to when to set it to > > false. > > In case we want to be able to use some of the topology information this > would mean we'd have two different mechanisms to either disable all > topology usage or only parts of it. I'd rather have a way to specify > which levels of the topology information (numa nodes, cache siblings, > core siblings) are to be used. Using none is just one possibility with > all levels disabled. > I agree, indeed, acting on has_mp seems overkill/not ideal to me too (I'm not even sure I fully understand how it's used in set_cpu_sibling_map()... I'll dig more). However... > >> > >>> Also, it seems to me that Xen guests would not be the only ones having > >>> to deal with topology inconsistencies due to migrating VCPUs. Don't KVM > >>> guests, for example, have the same problem? And if yes, perhaps we > >>> should try solving it in non-Xen-specific way (especially given that > >>> both of those patches look pretty simple and thus are presumably easy to > >>> integrate into common code). > >> > >> Indeed. I'll have a try. > >> ...yes, this is an interesting point, and it's worth try looking at how to implement things that way. Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy Dario Faggioli <dario.faggioli@citrix.com> - 2015-09-15 19:20 +0200
csiph-web