From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoJbU-0004Sz-Fi for qemu-devel@nongnu.org; Sun, 16 Jun 2013 16:31:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoJbR-0006K6-RT for qemu-devel@nongnu.org; Sun, 16 Jun 2013 16:31:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoJbR-0006K1-Ig for qemu-devel@nongnu.org; Sun, 16 Jun 2013 16:31:09 -0400 Date: Sun, 16 Jun 2013 23:31:55 +0300 From: "Michael S. Tsirkin" Message-ID: <20130616203154.GB19741@redhat.com> References: <1370805206-26574-1-git-send-email-afaerber@suse.de> <1370805206-26574-32-git-send-email-afaerber@suse.de> <87a9myzb25.fsf@blackfin.pond.sub.org> <51B643D8.9090909@suse.de> <87hah5xffi.fsf@blackfin.pond.sub.org> <51BDEAB4.2020502@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <51BDEAB4.2020502@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-cpu 31/59] monitor: Simplify do_info_numa() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Luiz Capitulino , Markus Armbruster , qemu-devel@nongnu.org On Sun, Jun 16, 2013 at 06:41:24PM +0200, Andreas F=E4rber wrote: > Am 11.06.2013 09:41, schrieb Markus Armbruster: > > Andreas F=E4rber writes: > >> If having patch 57/59 larger is not a concern (which getting rid of > >> open-coded CPU loops tried to address), then I can just convert the > >> loops in place alongside first_cpu / next_cpu. > >> Then still the question remains of whether you'd want to inline and = drop > >> qemu_for_each_cpu() afterwards, or whether we can establish some rul= es > >> of thumb when to use which? > >=20 > > To be honest, I see no value in qemu_for_each_cpu(). > >=20 > > At a glance, PATCH 57 looks fairly mechanical to me. Is it? Would i= t > > remain so if refrains from converting simple loops to > > qemu_for_each_cpu()? >=20 > v2 does that now. >=20 > Andreas I think it's a bad idea to have everyone looking at CPU state also care about the data structure used to keep all CPUs. If we switch to another datastructure what then? Rework it again? And I think it *would* be a good idea to rework it - there's a singly linked list there manually put together using the next_cpu pointer. We have macros for list manipulation, it should use that. > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg