Keir Fraser wrote:
> On 4/7/08 16:28, "Andre Przywara" <andre.przywara@amd.com> wrote:
> 
>> 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.
> 
> When sent a patch sequence I expect the patches to apply and work
> independently (when applied one-by-one in order).
IMHO that is what they do (beside the below issue patch 1 and 2 are more 
or less refactoring without functional changes), but anyway...

> Anyway, your second patch changes the default NUMA allocation policy from
> allocate on home node for the domain to allocate on node I'm currently
> executing on. That would seem a net loss for PV guests (whose builder will
> not be explicitly specifying the numa node for allocations).
Right you are, I have missed the subtle difference between both (the 
code isn't as clear as your sentence). The below patch should fix this 
(by catching NUMA_NO_NODE while still knowing struct domain*).
If there are no further issues, I will resend the patches.

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