Keir Fraser wrote:
On 4/7/08 13:48, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:
Looking some more, I still don't see that this patch can work. Don't the
subfunctions in memory.c go and OR in MEMF_node() values on top of what the
caller may have specified??
Maybe I don't get your question right, but the only part where the
caller specified node number is used is the line I handled in the last
patch. Later they only use the member memflags of struct memop_args, not
struct xen_memory_reservation. If the node number is not specified (or
blocked), it will be later determined by looking at the current
scheduled pCPU (and thus node), but this is the current behavior anyway.
Take common/memory.c:populate_physmap() as a specific example. It
unconditionally specifies MEMF_node() in its invocation of
alloc_domheap_pages(), regardless of whether its caller has already
specified a node in the memop_args structure that is passed into it.
Have you applied the patches correctly? From 02_numa_guest.patch:
@@ -115,7 +113,7 @@
goto out;
page = alloc_domheap_pages(
- d, a->extent_order, a->memflags | MEMF_node(node));
+ d, a->extent_order, a->memflags);
if ( unlikely(page == NULL) )
{
gdprintk(XENLOG_INFO, "Could not allocate order=%d extent:"
The other use of MEMF_node is in exchange_memory, which is not given any
NUMA node info from the caller, so this is correct.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home