[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/4] hvm: NUMA guest: extend memops hypercall


  • To: Andre Przywara <andre.przywara@xxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Fri, 04 Jul 2008 15:54:17 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 04 Jul 2008 07:54:46 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acjd5dTyE1HavknZEd2bbwAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH 1/4] hvm: NUMA guest: extend memops hypercall

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.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.