Re: [Xen-devel] [RFC][PATCH] domheap optimization for NUMA

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 3/4/08 11:39, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:

> By the way, can we solve the DMA_BITSIZE problem (your mail from 28th
> Feb) with this? If no node is specified, use the current behaviour of
> preferring non DMA zones, else stick to the given node.
> If you agree, I will implement this.

I don't think that gets us what we want. The fact is we specify NUMA node on
nearly 100% of allocations (either explicitly via MEMF_node() or via passing
a non-NULL domain pointer). So you would *always* prefer local DMA pages
over remote non-DMA pages. That's not necessarily better than the current
policy.

My point in my email of Feb 28th was that we should set dma_bitsize
'appropriately' (well, according to a slightly arbitrary policy :-) so that
*some* DMA memory is set aside and only used to satisfy allocations which
cannot be satisfied by a remote, while *some* memory is always made
available on every node for local allocations.

Does that make sense?

>> NUMA_NO_NODE probably needs to be pulled out of asm-x86/numa.h and made the
>> official arch-neutral way to specify 'don't care' for numa nodes.
> Is this really needed? I provided memflags=0 is all don't care cases,
> this should work and is more compatible. But beware that this silently
> assumes in page_alloc.c#alloc_domheap_pages that NUMA_NO_NODE is 0xFF,
> otherwise this trick will not work.

Yes it is needed if your patch is to work across all architectures, not just
x86! Your current patch is broken in this respect because you quite
unnecessarily define domain_to_node() and vcpu_to_node() in asm/numa.h
rather than xen/numa.h.

Please address architectural portability and re-send the patch. Apart from
that I think it's just about ready to go in.

 Thanks,
 Keir

> Attached again a diff against my last version and the full patch (for
> some reason a missing bracket slipped through my last one, sorry for that).
> 
> This is only quick-tested (booted and created a guest on each node).



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel