[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest

On 07/28/2015 01:19 AM, Andrew Cooper wrote:
On 27/07/2015 18:42, Dario Faggioli wrote:
On Mon, 2015-07-27 at 17:33 +0100, Andrew Cooper wrote:
On 27/07/15 17:31, David Vrabel wrote:

Yeah, indeed.
That's the downside of Juergen's "Linux scheduler
approach". But the issue is there, even without taking vNUMA into
account, and I  think something like that would really help (only for
Dom0, and Linux guests, of course).
I disagree.  Whether we're using vNUMA or not, Xen should still ensure
that the guest kernel and userspace see a consistent and correct
topology using the native mechanisms.


+1 from me as well. In fact, a mechanism for making exactly such thing
happen, was what I was after when starting the thread.

Then it came up that CPUID needs to be used for at least two different
and potentially conflicting purposes, that we want to support both and
that, whether and for whatever reason it's used, Linux configures its
scheduler after it, potentially resulting in rather pathological setups.

I don't see what the problem is here.  Fundamentally, "NUMA optimise" vs
"comply with licence" is a user/admin decision at boot time, and we need
not cater to both halves at the same time.

Supporting either, as chosen by the admin, is worthwhile.

Wrong assumption again. *It's not only about NUMA*!

The choice is: "comply with license" against "sane scheduling". NUMA
just makes it more obvious, that the data the guest's scheduling
decisions are based on is garbage as soon as you tell the guest there
are hyperthreads without pinning the vcpus.

Right now the sibling information is more or less random leading
eventually to some vcpus thinking they have no sibling at all. As soon
as you deliver sibling information based on vcpu number you might end
up with a deterministic bad scheduling behaviour.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.