[Qemu-devel] [PATCH 3/8] v2: add info numa monitor command

[Qemu-devel] [PATCH 3/8] v2: add info numa monitor command

[Andre Przywara]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Signed-off-by: Andre Przywara <andre.przywara@amd.com>

-- 
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

[-- Attachment #2: qemunuma_v2_monitor_info.patch --]
[-- Type: text/x-patch, Size: 1239 bytes --]

# HG changeset patch
# User Andre Przywara <andre.przywara@amd.com>
# Date 1229430525 -3600
# Node ID 0f3054b66373c2a8b65a5be6d83af63f807dd88f
# Parent  a0a2e3026d4acffdce91b776d8c2d733767693c5
add info numa command to the monitor

diff -r a0a2e3026d4a -r 0f3054b66373 monitor.c
--- a/monitor.c	Tue Dec 16 13:28:24 2008 +0100
+++ b/monitor.c	Tue Dec 16 13:28:45 2008 +0100
@@ -1281,6 +1281,20 @@ static void do_info_kvm(void)
 #endif
 }
 
+static void do_info_numa(void)
+{
+    int i, j;
+
+    term_printf("%d nodes\n", numnumanodes);
+    for (i = 0; i < numnumanodes; i++) {
+        term_printf("node %d cpus:", i);
+        for (j = 0; j < 64; j++)
+            if (node_to_cpus[i] & (1ULL << j)) term_printf(" %d", j);
+        term_printf("\n");
+        term_printf("node %d size: %" PRId64 " MB\n", i, node_mem[i] >> 20);
+    }
+}
+
 #ifdef CONFIG_PROFILER
 
 int64_t kqemu_time;
@@ -1538,6 +1552,8 @@ static const term_cmd_t info_cmds[] = {
       "", "show kqemu information", },
     { "kvm", "", do_info_kvm,
       "", "show kvm information", },
+    { "numa", "", do_info_numa,
+      "", "show NUMA information", },
     { "usb", "", usb_info,
       "", "show guest USB devices", },
     { "usbhost", "", usb_host_info,

[Qemu-devel] Re: [PATCH 3/8] v2: add info numa monitor command

[Anthony Liguori]

Andre Przywara wrote:
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>
>
> # HG changeset patch
> # User Andre Przywara <andre.przywara@amd.com>
> # Date 1229430525 -3600
> # Node ID 0f3054b66373c2a8b65a5be6d83af63f807dd88f
> # Parent  a0a2e3026d4acffdce91b776d8c2d733767693c5
> add info numa command to the monitor
>
> diff -r a0a2e3026d4a -r 0f3054b66373 monitor.c
> --- a/monitor.c	Tue Dec 16 13:28:24 2008 +0100
> +++ b/monitor.c	Tue Dec 16 13:28:45 2008 +0100
> @@ -1281,6 +1281,20 @@ static void do_info_kvm(void)
>  #endif
>  }
>  
> +static void do_info_numa(void)
> +{
> +    int i, j;
> +
> +    term_printf("%d nodes\n", numnumanodes);
> +    for (i = 0; i < numnumanodes; i++) {
> +        term_printf("node %d cpus:", i);
> +        for (j = 0; j < 64; j++)
> +            if (node_to_cpus[i] & (1ULL << j)) term_printf(" %d", j);
>   

So the current code limits us to 64-cpus?  That's a pretty serious 
limitation IMHO.  I think that strongly suggests we're using the wrong 
structures for node_to_cpus--especially to be in the BIOS FW interface.

Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH 3/8] v2: add info numa monitor command

[Andre Przywara]

Anthony Liguori wrote:

> So the current code limits us to 64-cpus?  That's a pretty serious 
> limitation IMHO.
I know, but I was hoping that a simpler patch would be easier to merge. 
So I am happy to fix it later and lift this restriction.
I searched for some kind of variable length bitmap type (like Linux' 
cpu_set_t) already being used in QEMU, but couldn't find anything 
appropriate. Do you know something? If you look at the glibc cpu_set_t 
implementation (in bits/sched.h), you surely want to make this a 
separate patch.

> I think that strongly suggests we're using the wrong 
> structures for node_to_cpus--especially to be in the BIOS FW interface.
Ok, this could be a point, but is this BIOS FW interface really a stable 
interface we cannot change later easily? IMHO this is QEMU (and derived 
projects) only, which always provide a matching BIOS anyway.

What about if I prepare the BIOS FW interface for future expansion and 
stick to the current uint64_t type for now?

Regards,
Andre.

And by the way: 64 core machines are _not_ common today, especially not 
when hosting pure QEMU :-)

-- 
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

[Qemu-devel] Re: [PATCH 3/8] v2: add info numa monitor command

[Anthony Liguori]

Andre Przywara wrote:
> Anthony Liguori wrote:
>
>> So the current code limits us to 64-cpus?  That's a pretty serious 
>> limitation IMHO.
> I know, but I was hoping that a simpler patch would be easier to 
> merge. So I am happy to fix it later and lift this restriction.
> I searched for some kind of variable length bitmap type (like Linux' 
> cpu_set_t) already being used in QEMU, but couldn't find anything 
> appropriate. Do you know something? If you look at the glibc cpu_set_t 
> implementation (in bits/sched.h), you surely want to make this a 
> separate patch.

I don't know that there's anything immediately obvious to use.

>> I think that strongly suggests we're using the wrong structures for 
>> node_to_cpus--especially to be in the BIOS FW interface.
> Ok, this could be a point, but is this BIOS FW interface really a 
> stable interface we cannot change later easily? IMHO this is QEMU (and 
> derived projects) only, which always provide a matching BIOS anyway.
>
> What about if I prepare the BIOS FW interface for future expansion and 
> stick to the current uint64_t type for now?

Please make the BIOS FW interface and the BIOS patch able to handle > 64 
cpus.  It's relatively painful to get stuff merged into Bochs and sync 
the BIOS.  I don't want to have to go through that again in the near 
future once Jes gets wind of the fact that you're limiting us to 64 cpus ;-)

I can live with QEMU being limited to 64 cpus for now.

> Regards,
> Andre.
>
> And by the way: 64 core machines are _not_ common today, especially 
> not when hosting pure QEMU :-)

It all depends on your perspective.  At any rate, the Core i7's 
reintroduce hyperthreading so you're looking at 16-way CPUs once the 
octal cores are released.  I'm not sure the time frame, but I think 
12-core CPUs are in the near future two from both Intel and AMD.  A 
single 4-socket board will be 64-way.  A multi-node system will easily 
be > 64-way.  This isn't long term future things, this is stuff that'll 
be relatively common next year.

Regards,

Anthony Liguori