From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1cM0-0005cw-CV for qemu-devel@nongnu.org; Fri, 10 Jan 2014 08:42:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1cLv-0000mW-0P for qemu-devel@nongnu.org; Fri, 10 Jan 2014 08:42:28 -0500 Received: from mail-pb0-f43.google.com ([209.85.160.43]:40242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1cLu-0000mH-QY for qemu-devel@nongnu.org; Fri, 10 Jan 2014 08:42:22 -0500 Received: by mail-pb0-f43.google.com with SMTP id rq2so4476769pbb.2 for ; Fri, 10 Jan 2014 05:42:21 -0800 (PST) Message-ID: <52CFF8B8.7010605@ozlabs.ru> Date: Sat, 11 Jan 2014 00:42:16 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1389245648-10300-1-git-send-email-aik@ozlabs.ru> <87ppo0na45.fsf@pixel.localdomain> <52CF1ECC.3040208@ozlabs.ru> <52CF4F37.4050306@ozlabs.ru> <878uuof0pu.fsf@pixel.localdomain> <84B5F34E-6072-4E56-8493-AAC69B9F7DAE@suse.de> In-Reply-To: <84B5F34E-6072-4E56-8493-AAC69B9F7DAE@suse.de> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2] PPC: smp: autodetect numbers of threads per core List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , Mike Day Cc: Paul Mackerras , "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" On 01/11/2014 12:28 AM, Alexander Graf wrote: > > On 10.01.2014, at 14:03, Mike Day wrote: > >> >> Alexey Kardashevskiy 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. I am not changing the default here. I am adding an ability to choose the maximum. > 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? Nope. I will need to smp_threads=min(smp_threads, 4) (and I do this in my patches which I think I already posted but I need to repost them) so if it is 1 by default, it will be still 1. > 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. Again. I do not change the default. I add an additional option (which is false by default) to use the maximum of the CPU. What harm can it possibly make? I am definitely missing your point, sorry. > > > Alex > -- Alexey