From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za4ff-0002nX-SC for qemu-devel@nongnu.org; Thu, 10 Sep 2015 12:26:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za4fb-0000pg-Tj for qemu-devel@nongnu.org; Thu, 10 Sep 2015 12:25:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za4fb-0000pb-OZ for qemu-devel@nongnu.org; Thu, 10 Sep 2015 12:25:55 -0400 References: <1438966995-5913-1-git-send-email-a.rigo@virtualopensystems.com> <1438966995-5913-2-git-send-email-a.rigo@virtualopensystems.com> <55C9FE29.2080204@redhat.com> <55CA1AF8.1090409@redhat.com> <55CA2383.60805@redhat.com> <55CB3DEA.2050103@redhat.com> From: Paolo Bonzini Message-ID: <55F1AF0E.6060704@redhat.com> Date: Thu, 10 Sep 2015 18:25:50 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 1/9] exec.c: Add new exclusive bitmap to ram_list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alvise rigo Cc: mttcg@greensocs.com, Claudio Fontana , QEMU Developers , Jani Kokkonen , VirtualOpenSystems Technical Team , =?UTF-8?Q?Alex_Benn=c3=a9e?= On 10/09/2015 15:04, alvise rigo wrote: > Hi Paolo, > > A brief update on this. I have a first implementation of the idea you > proposed, though it's not working really well. The failing rate of SCs > for some reason is very high. > Instead of trying to fix it, I came up with this alternative design: > we still use 8 bits per page and we group the smp_cpus in clusters of > maximum size ceiling(smp_cpus / 8). > Given a byte describing a certain page, its first bit will represents > the vCPUs of index 0, 9, 17, ... and so on for the other bits. > > Note that systems with eight vCPUs or less will not be affected by > this simplified model. > > Now, unless I'm missing some advantages of your proposal except the > less aggressive memory consumption, I would go with this design. Sounds great. Paolo