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

[Anthony Liguori <anthony@codemonkey.ws>]

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