All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <Andrew.Cooper3@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy
Date: Tue, 15 Sep 2015 19:16:58 +0200	[thread overview]
Message-ID: <1442337418.7789.52.camel@citrix.com> (raw)
In-Reply-To: <55E707E9.6000805@suse.com>

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

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)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2015-09-15 17:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 15:55 [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy Dario Faggioli
2015-08-18 16:53 ` Konrad Rzeszutek Wilk
2015-08-20 18:16 ` Juergen Groß
2015-08-31 16:12   ` Boris Ostrovsky
2015-09-02 11:58     ` Juergen Gross
2015-09-02 14:08       ` Boris Ostrovsky
2015-09-02 14:30         ` Juergen Gross
2015-09-15 17:16           ` Dario Faggioli [this message]
2015-09-15 16:50   ` [Xen-devel] " Dario Faggioli
2015-09-21  5:49     ` Juergen Gross
2015-09-22  4:42       ` Juergen Gross
2015-09-22 16:22         ` George Dunlap
2015-09-23  4:36           ` Juergen Gross
2015-09-23  8:30             ` Dario Faggioli
2015-09-23  9:44               ` Juergen Gross
2015-09-23 10:23             ` George Dunlap
2015-09-23  7:24       ` Dario Faggioli
2015-09-23  7:35         ` Juergen Gross
2015-09-23 12:25           ` Boris Ostrovsky
2015-08-27 10:24 ` George Dunlap
2015-08-27 17:05   ` [Xen-devel] " George Dunlap
2015-09-15 14:32   ` Dario Faggioli

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=1442337418.7789.52.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.