From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmiZf-0001Tz-BZ for qemu-devel@nongnu.org; Fri, 07 Nov 2014 07:23:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmiZS-0002AT-Ef for qemu-devel@nongnu.org; Fri, 07 Nov 2014 07:23:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmiZR-00029t-Lh for qemu-devel@nongnu.org; Fri, 07 Nov 2014 07:23:17 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA7CNGc1004433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 7 Nov 2014 07:23:16 -0500 Date: Fri, 7 Nov 2014 13:23:12 +0100 From: Andrew Jones Message-ID: <20141107122312.GA10985@hawk.usersys.redhat.com> References: <1415290175-17314-1-git-send-email-drjones@redhat.com> <545BF212.2090404@redhat.com> <20141107092935.GB3004@hawk.usersys.redhat.com> <545C937E.6020106@redhat.com> <20141107095230.GA6518@hawk.usersys.redhat.com> <20141107112126.GB6518@hawk.usersys.redhat.com> <20141107121606.GG3196@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141107121606.GG3196@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH] vl: rework smp_parse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Paolo Bonzini , qemu-devel@nongnu.org On Fri, Nov 07, 2014 at 10:16:06AM -0200, Eduardo Habkost wrote: > On Fri, Nov 07, 2014 at 12:21:26PM +0100, Andrew Jones wrote: > > On Fri, Nov 07, 2014 at 10:52:31AM +0100, Andrew Jones wrote: > > > On Fri, Nov 07, 2014 at 10:40:14AM +0100, Paolo Bonzini wrote: > > > > > > > > > > > > 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. > > > > > > OK. I can whip up a v2 that is less harsh (more warnings, less aborts). > > > I'll also address the other issue I mentioned in the bottom of my reply > > > to Eduardo, which is to make sure we consider machine_class->max_cpus. > > > > After talking with Igor, it seems like the better approach is to get > > smp parameters converted over to machine properties, allowing us to > > use the old parser for old machine types, and the new for new. I'll > > look into it. > > While we work on that, I think we could at least change the existing > code to abort if sockets*cores*threads < smp_cpus (when all 4 options > are present in the command-line), and never adjust any option silently. But then we'll end up with 3 different behaviors. If we do anything for the short-term, then maybe it should only be to add warnings. The machine property version will then convert those warnings to aborts for new machines types. drew