From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1R4O-0000PX-1N for qemu-devel@nongnu.org; Thu, 09 Jan 2014 20:39:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1R48-0008PJ-KO for qemu-devel@nongnu.org; Thu, 09 Jan 2014 20:39:31 -0500 Received: from mail-pd0-f169.google.com ([209.85.192.169]:54589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1R48-0008Ov-Dl for qemu-devel@nongnu.org; Thu, 09 Jan 2014 20:39:16 -0500 Received: by mail-pd0-f169.google.com with SMTP id v10so3929766pde.0 for ; Thu, 09 Jan 2014 17:39:15 -0800 (PST) Message-ID: <52CF4F37.4050306@ozlabs.ru> Date: Fri, 10 Jan 2014 12:39:03 +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> In-Reply-To: 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 Cc: Mike Day , Paul Mackerras , "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" On 01/10/2014 10:40 AM, Alexander Graf wrote: > > >> Am 09.01.2014 um 23:12 schrieb Alexey Kardashevskiy : >> >>> On 01/10/2014 08:00 AM, Mike Day wrote: >>> >>> Alexey Kardashevskiy writes: >>> >>>> /* compute missing values, prefer sockets over cores over threads */ >>>> if (cpus == 0 || sockets == 0) { >>>> sockets = sockets > 0 ? sockets : 1; >>>> cores = cores > 0 ? cores : 1; >>>> - threads = threads > 0 ? threads : 1; >>>> + if (threads_max) { >>>> + if (threads > 0) { >>>> + fprintf(stderr, "Use either threads or threads_max\n"); >>>> + exit(1); >>> >>> If you went ahead with the threads="max" string option you wouldn't need >>> to check here for mutual excusivity and the user wouldn't need to worry >>> about an extra command options. >> >> >> Is this the only concern and the rest is fine and can go to upstream? If >> so, I'll fix it and repost. > > 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". >>From what you said I conclude that we add this "max" property only to the "host" CPU type and then in smp_parse() we look if "host" CPU is going to be used and if so, then we read "max" property from it and use it. But we cannot read property for a class, only from an instance and it is not created yet. And we also need to tweak the number depending on "compat". And we still need "-smp ...threads_max" or "-smp ...threads=max" property for "-smp". Where am I wrong here? > Overall I'm not yet fully convinced this whole idea is eventually going > to improve the situation though. My goal is to have a script which would automatically set threads to the maximum value supported by the host hardware. Reading /proc/cpuinfo and parsing for POWER6/7/8 and setting threads to 2/4/8 is lame for my taste because what was the point of adding cap_ppc_smt at the first place then? > > > Alex > >> >> >>>> + } >>>> + threads = smp_threads > 0 ? smp_threads : 1; >>>> + } else { >>>> + threads = threads > 0 ? threads : 1; >>>> + } >>>> if (cpus == 0) { >>>> cpus = cores * threads * sockets; >>>> } >> >> >> -- >> Alexey -- Alexey