On 10.01.2014, at 14:03, Mike Day <ncm...@ncultra.org> wrote: > > Alexey Kardashevskiy <a...@ozlabs.ru> writes: > >> On 01/10/2014 10:40 AM, Alexander Graf wrote: >>> >> >>> What if we make the max thread count a property of our cpu class? The >>> we >> can add a threads=max option which will be identical between kvm and tcg. >> >> >> You lost me here :) >> Right now the sequence is: >> 1. smp_parse >> 2. config_accelerator >> 3. machine_init >> >> I proposed >> 1. config_accelerator - reads max threads from KVM (and initializes "host" >> type) >> 2. smp_parse - does the parsing using smp_threads tweaked in 1) >> 3. machine_init - creates CPUs which may or may be not "host". > > The patch as it its now is very simple and well-contained. I wonder how > much it would expand if we added a max thread count to the cpu class. It > seems like the need for a max thread count is idiomatic to powerpc.
It's only ever useful on IBM POWER. Any other PowerPC system can partition vcpus by host threads, it's only IBM POWER hardware that's as broken as it is. But really, what problem are you trying to solve here? Do you have users that don't understand the constraints they have? You will still have this even with this patch, as if you do threads=max as default for KVM (which is a bad idea, because it diverges from TCG) -smp 5 would still allocate 2 host cores on p7 and you're not effectively using your resources. With the patch you're also not taking compat thread count into account. A POWER7 compat system would still need to manually specify threads=4, no? I do see that the user experience is slightly suboptimal, but by creating this special case there's a good chance you're doing more harm than good. Alex
