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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/07/15 04:52, Juergen Gross wrote:
> 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
>>>>
>>> +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.

Fine.  s/NUMA/scheduling/

But the point still stands.  The CPUID information should be consistent
with other sources of information.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel