Re: PV-vNUMA issue: topology is misinterpreted by the guest

[Juergen Gross <jgross@suse.com>]

On 07/27/2015 04:34 PM, Boris Ostrovsky wrote:
> On 07/27/2015 10:09 AM, Dario Faggioli wrote:
>> On Fri, 2015-07-24 at 18:10 +0200, Juergen Gross wrote:
>>> On 07/24/2015 05:58 PM, Dario Faggioli wrote:
>>>> So, just to check if I'm understanding is correct: you'd like to add an
>>>> abstraction layer, in Linux, like in generic (or, perhaps, scheduling)
>>>> code, to hide the direct interaction with CPUID.
>>>> Such layer, on baremetal, would just read CPUID while, on PV-ops, it'd
>>>> check with Xen/match vNUMA/whatever... Is this that you are saying?
>>> Sort of, yes.
>>>
>>> I just wouldn't add it, as it is already existing (more or less). It
>>> can deal right now with AMD and Intel, we would "just" have to add Xen.
>>>
>> So, having gone through the rest of the thread (so far), and having
>> given a fair amount o thinking to this, I really think that something
>> like this would be a good thing to have in Linux.
>>
>> Of course, it's not that my opinion on where should be in Linux counts
>> that much! :-D   Nevertheless, I wanted to make it clear that, while
>> skeptic at the beginning, I now think this is (part of) the way to go,
>> as I said and explained in my reply to George.
>
> And I continue to believe that kernel solution does not address the
> userland problem which is no less important than making kernel do proper
> scheduling decisions (and I suspect when this patch goes for review
> that's what the scheduling people are going to say).

I didn't say it would solve that problem. It would decouple kernel
scheduling and cpuid values in order to be free to present cpuid values
to user land needed there.


Juergen