Re: [PATCH 0/3][RFC] NUMA: add host side pinning

[Andre Przywara <andre.przywara@amd.com>]

Jes Sorensen wrote:
> On 06/24/10 13:34, Andre Przywara wrote:
>> Avi Kivity wrote:
>>> On 06/24/2010 01:58 PM, Andre Przywara wrote:
>>> Non-anonymous memory doesn't work well with ksm and transparent
>>> hugepages.  Is it possible to use anonymous memory rather than file
>>> backed?
>> I'd prefer non-file backed, too. But that is how the current huge pages
>> implementation is done. We could use MAP_HUGETLB and declare NUMA _and_
>> huge pages as 2.6.32+ only. Unfortunately I didn't find an easy way to
>> detect the presence of the MAP_HUGETLB flag. If the kernel does not
>> support it, it seems that mmap silently ignores it and uses 4KB pages
>> instead.
> 
> Bit behind on the mailing list, but I think this look very promising.
> 
> I really think it makes more sense to make QEMU aware of the NUMA setup
> as well, rather than relying on numctl to do the work outside.
> 
> One thing you need to consider is what happens with migration once a
> user specifies -numa. IMHO it is acceptable to simply disable migration
> for the given guest.
Is that really a problem? You create the guest on the target with a NUMA 
setup specific to the target machine. That could mean that you pin 
multiple guest nodes to the same host node, but that shouldn't break 
something, right? The guest part can (and should be!) migrated along 
with all the other device state. I think this is still missing from the 
current implementation.

> 
> Cheers,
> Jes
> 
> PS: Are you planning on submitting anything to Linux Plumbers Conference
> about this? :)
Yes, I was planning to submit a proposal, as I saw NUMA mentioned in the 
topics list. AFAIK the deadline is July 19th, right? That gives me 
another week after my vacation (for which I leave in a few minutes).

Regards,
Andre.


-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712