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

Re: [Xen-devel] Host Numa informtion in dom0



Kamble, Nitin A wrote:
Hi Keir,

Attached is the patch which exposes the host numa information to dom0. With the patch “xm info” command now also gives the cpu topology & host numa information. This will be later used to build guest numa support.
What information are you missing from the current physinfo? As far as I can see, only the total amount of memory per node is not provided. But one could get this info from parsing the SRAT table in Dom0, which is at least mapped into Dom0's memory. Or do you want to provide NUMA information to all PV guests (but then it cannot be a sysctl)? This would be helpful, as this would avoid to enable ACPI parsing in PV Linux for NUMA guest support.

Beside that I have to oppose the introduction of sockets_per_node again. Future AMD processors will feature _two_ nodes on _one_ socket, so this variable should hold 1/2, but this will be rounded to zero. I think this information is pretty useless anyway, as the number of sockets is mostly interesting for licensing purposes, where a single number is sufficient. For scheduling purposes cache topology is more important.

My NUMA guest patches (currently for HVM only) are doing fine, I will try to send out a RFC patches this week. I think they don't interfere with this patch, but if you have other patches in development, we should sync on this. The scope of my patches is to let the user (or xend) describe a guest's topology (either by specifying only the number of guest nodes in the config file or by explicitly describing the whole NUMA topology). Some code will assign host nodes to the guest nodes (I am not sure yet whether this really belongs into xend as it currently does, or is better done in libxc, where libxenlight would also benefit). Then libxc's hvm_build_* will pass that info into the hvm_info_table, where code in the hvmloader will generate an appropriate SRAT table. An extension of this would be to let Xen automatically decide whether a split of the resources is necessary (because there is not enough memory available (anymore) on one node).

Looking forward to comments...

Regards,
Andre.

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448 3567 12
----to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Andrew Bowd; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
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®.