On Mon, 2015-07-27 at 10:34 -0400, Boris Ostrovsky wrote:
> On 07/27/2015 10:09 AM, Dario Faggioli wrote:

> > 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 
>
Sure, but the key point now is, IMO, whether we recognise that we're
dealing with two problems, which I think is the case.

One problem is:
 1. CPUID in VMs is unreliable, can we rely on it as few as possible?

The other problem is:
 2. if someone wants to rely on CPUID, what should we do.

Avoiding the scheduling domains (and/or whatever else!) to relay on
something that is unreliable by definition, which is what is being
proposed, seems to me a pretty decent solution to 1.

> (and I suspect when this patch goes for review 
> that's what the scheduling people are going to say).
> 
Perhaps. However, I may be too optimistic, but I think that making them
realize that all we are doing is stopping relying on unreliable grounds
would not be impossible... Especially if the code really looks as
Juergen said, i.e., it's already quite friendly to implementing
something like this...

> Remember the original problem that started this thread was that kernel 
> complained that topology didn't make sense and it turned off all 
> topology-related decisions. Which means that kernel already has a 
> solution for weird topology. Some enumeration doesn't trigger this 
> warning, but we can come up with one that does.
>
Exactly, because it relies on CPUID, which is unreliable!! :-)

> Or we can indeed have a 
> patch in kernel that will, possibly silently, fail topology_sane() when 
> virtualized and not pinned.
> 
Well, I think that, if I were a Linux scheduler or x86 maintainer, I
would oppose much more to a similar patch, rather than to one that makes
the kernel stop relying on an instruction that gives pCPU specific
results, to build-up long lived information, in a context where pCPUs
change. :-)

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)