[Xen-devel] Re: [PATCH 2/6][RESEND] xen: Add NUMA support to Xen

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 12 May 2006, at 16:12, Ryan Harper wrote:

> > Then in
> > init_domheap_pages(), there are no calls to memguard, just
> > work to set up the range for a call to init_heap_pages().  I'm
> > not sure if I need to use memguard for marking the chunk
> > boundaries, or if just reserving chunk boundaries that weren't
> > already on a MAX_ORDER edge via map_alloc() is sufficient.
Just reserving is sufficient. memguard is a debug-build aid for xen 
heap only.
> > Also, I didn't see a way to ensure reserved pages aren't freed via a
> > call to init_heap_pages() which just clears out a range of bits in
> > the alloc map.  Should we be worried about that?
Well, in theory. It's only called in one place though right now, and 
probably with a physical range below 128MB in all cases. So it's 
unlikely to straddle a NUMA boundary.
Another comment on this patch (2/2): page_to_node() should be defined 
in numa.c (for now) rather than page_alloc.c (where it will never 
belong). I know you also directly scan the chunk array to find 
boundaries to reserve: perhaps for now we could have 
end_boot_allocator() call init_heap_pages() for each page, then 
initheap_pages() can compare page_to_node(page) with 
page_to_node(page-1). If they differ and the latter is not -1 and page 
is not on a MAX_ORDER boundary, then you do not free the page to the 
buddy allocator.
Clearly this will be crappily slow, but it's only used at boot time and 
as long as it's not *too* bad (which it certainly won't be for short 
chunk lists) then it'll do until we improve things (probably with a 
fast constant-time page_to_node() implementation).
The main thing here is to get the interfaces right, and the current 
export of memory_chunk structure and array is definitely not right. I'd 
like it to remain hidden in numa.c/srat.c as it is on Linux, or at 
least hidden in arch/x86. It also lets us stub out page_to_node() 
easily for ia64, and breaks them a whole lot less.
 -- Keir

> > Attached is what the current working patch looks like.  Let me know if
> > this is more to your liking.  If so, I'll re-spin the whole patchset 
> > and
> > test it across the set of test machines we have (NUMA and non-NUMA).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel