From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2eIJ-0002dx-Hh for qemu-devel@nongnu.org; Fri, 26 Jul 2013 05:26:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2eII-0002e8-D9 for qemu-devel@nongnu.org; Fri, 26 Jul 2013 05:26:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2eII-0002dx-4e for qemu-devel@nongnu.org; Fri, 26 Jul 2013 05:26:38 -0400 Message-ID: <51F240B8.3070303@redhat.com> Date: Fri, 26 Jul 2013 11:26:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374596592-7027-1-git-send-email-imammedo@redhat.com> <1374596592-7027-11-git-send-email-imammedo@redhat.com> <51EEB8C6.1030601@redhat.com> <20130724103622.73cf0869@nial.usersys.redhat.com> <51EFA130.5050400@redhat.com> <20130724133420.5c0c5653@nial.usersys.redhat.com> <51EFCB80.50308@redhat.com> <20130726093840.41bd7106@nial.usersys.redhat.com> In-Reply-To: <20130726093840.41bd7106@nial.usersys.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/16] dimm: add busy slot check and slot auto-allocation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: vasilis.liaskovitis@profitbricks.com, hutao@cn.fujitsu.com, qemu-devel@nongnu.org Il 26/07/2013 09:38, Igor Mammedov ha scritto: > Perhaps denying memory add and suggesting node migration to a node with > more memory would be right approach, otherwise user is bound to be hit by > cross node penalty. Or better, the user can first change the policy from "bind" to "preferred", and then hotplug. >> > I agree that specifying the policy on every hotplug complicates >> > management and may be overkill. But then, most guests are not NUMA at >> > all and you would hardly perceive the difference, you would just have to >> > separate >> > >> > set-mem-policy 0 size=2G >> > device_add dimm,slot=0 > I'm confused, size is inherent property of generic DimmDevice and policies > are NUMA specific of node. No, the size is not a property of the DimmDevice, it is a property of the host object that backs the DimmDevice. This is like the size is not a property of a disk, but rather of the image that backs it. Now, there may be a good reason to remove the host/guest distinction in the case of memory, but I'm still not sure this is the case. In the case of NUMA policies, I talked to Andrea Arcangeli and indeed his suggestion was to have a single policy per guest node (typically bind or preferred if guest node size <= host node size, interleave if guest node size > host node size). However, there are other properties of the memory object (e.g. hugetlbfs path) that could be customized for every slot. Paolo > If there is need for per DIMM policies, I'd store NUMA specific policy inside > object that implements it (allocates memory), and apply them to DIMM when > it's realized. > > set-mem-policy nodeid=X,mem-hostnodes=Z,dev=dimmY > device_add dimm,id=dimmY,size=2G,node=X >