From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmg1p-0004e6-Qc for qemu-devel@nongnu.org; Fri, 07 Nov 2014 04:40:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xmg1j-000720-Dd for qemu-devel@nongnu.org; Fri, 07 Nov 2014 04:40:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmg1j-00071o-72 for qemu-devel@nongnu.org; Fri, 07 Nov 2014 04:40:19 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA79eIxO000678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 7 Nov 2014 04:40:18 -0500 Message-ID: <545C937E.6020106@redhat.com> Date: Fri, 07 Nov 2014 10:40:14 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1415290175-17314-1-git-send-email-drjones@redhat.com> <545BF212.2090404@redhat.com> <20141107092935.GB3004@hawk.usersys.redhat.com> In-Reply-To: <20141107092935.GB3004@hawk.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] vl: rework smp_parse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: qemu-devel@nongnu.org, ehabkost@redhat.com On 07/11/2014 10:29, Andrew Jones wrote: >> > I think this would cause too many failures in the wild. Perhaps error >> > out if it is lower, and warn if sockets * cores * threads > max_cpus >> > since we actually allow hot-plug a thread at a time? > We'd still have more failures if we choose to error out when it's lower, > since we currently silently adjust threads in some of those cases, or > just don't care that the topology doesn't support up to maxcpus in other. So I guess we need a decent fallback if it doesn't match. Something like (based also on the reply from Eduardo): 1) always warn if max_cpus % (cores*threads) != 0 || smp_cpus % (cores*threads) != 0 2) if sockets*cpus*threads < max_cpus, adjust sockets to DIV_ROUND_UP(max_cpus, cores*threads). If we didn't warn in step 1, do it now. Give a different, less harsh warning if the cmdline sockets*cpus*threads did match smp_cpus. In the latter case, the user _almost_ knows what he was doing. Not perfect, but it could be something to start from. Adjusting sockets is better than adjusting threads. Paolo > I'm not sure how best to go about modifying the command line semantics > in a backwards compatible way, other than to just create a new "-smp" > option. I'm open to all opinions and suggestions.