RE: [Xen-devel] [PATCH 0/6] xen,xend,tools: NUMA support for Xen

["Lu, Yinghai" <yinghai.lu@xxxxxxx>]

So the virtual firmware need to have SRAT table in acpi tables. Or the
ioemu need to have NB device So the guest OS can get the numa info.

Also windows smp guest will need info to understand core to socket
mapping so it could enable two sockets ( 4 cores ).
So xen need to pass enough info about nodes-cores mapping to virtual
firmare and ioemu. So ioemu could put info in NB conf, and virtual
firmware apci tables. (---svm msr intercept for cores setting related
need to be changed too).

YH


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: Tuesday, July 11, 2006 8:58 AM
To: Ryan Harper
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH 0/6] xen,xend,tools: NUMA support for
Xen


On 11 Jul 2006, at 16:35, Ryan Harper wrote:

> Reposting the latest patches, no significant changes since May when I
> last received feedback.  I've done some simple overhead and
performance
> numbers for these patches.
>
> Measuring NUMA allocator patch overhead via balloon driver and DOM0
> involved starting DOM0 with all memory (4G) and ballooning down (256M)
> as a starting point, [1]tracking the time it takes to balloon back up
> to full memory.  The test was done with and without NUMA patches.

What sort of box are these numbers taken from? If it's not a NUMA 
system then the slowdowns are rather poor. We're particularly 
interested in not slowing down non-NUMA and small-NUMA (e.g., AMD K8) 
x86 systems. They are what we really want to see measurements from.

  -- Keir


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




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