From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIfQj-0004xM-6J for qemu-devel@nongnu.org; Wed, 26 Feb 2014 09:25:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIfQd-00021T-7k for qemu-devel@nongnu.org; Wed, 26 Feb 2014 09:25:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIfQc-00021M-QT for qemu-devel@nongnu.org; Wed, 26 Feb 2014 09:25:43 -0500 Date: Wed, 26 Feb 2014 15:25:24 +0100 From: Igor Mammedov Message-ID: <20140226152524.4fee536f@nial.usersys.redhat.com> In-Reply-To: <530DF070.7020803@redhat.com> References: <53047351.80300@redhat.com> <20140219103657.4daed264@nial.usersys.redhat.com> <20140226055706.GA5090@G08FNSTD100614.fnst.cn.fujitsu.com> <20140226101056.1a9ec3b3@nial.usersys.redhat.com> <530DC2FA.9080401@redhat.com> <20140226133119.3ccca5a3@nial.usersys.redhat.com> <530DE1F2.6060701@redhat.com> <20140226144333.5ed8e07e@nial.usersys.redhat.com> <530DF070.7020803@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v18 13/14] memory backend: fill memory backend ram fields List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Hu Tao , Marcelo Tosatti , lersek@redhat.com, qemu-devel@nongnu.org, Wanlong Gao On Wed, 26 Feb 2014 14:47:28 +0100 Paolo Bonzini wrote: > Il 26/02/2014 14:43, Igor Mammedov ha scritto: > > On Wed, 26 Feb 2014 13:45:38 +0100 > > Paolo Bonzini wrote: > > > >> Il 26/02/2014 13:31, Igor Mammedov ha scritto: > >>>>> The problem is that some backends might not be handled the same way. > >>>>> For example, not all backends might produce a single void*/size_t pair > >>>>> for the entire region. Think of a "composite" backend that produces a > >>>>> large memory region from two smaller ones. > >>> I'd prefer to keep backends simple, with 1:1 mapping to memory regions. > >> > >> I agree. However not all backends may have a mapping to a RAM memory > >> region. A composite backend could create a container memory region > >> whose children are other HostMemoryBackend objects. > >> > >>> Is there a need in composite one or something similar? > >> > >> I've heard of users that want a node backed partially by hugetlbfs and > >> partially by regular RAM. Not sure why. > > Isn't issue here in how backend is mapped into GPA? Well that is not > > backend's job. > > > > Once one starts to put layout (alignment, noncontinuously mapped > > memory regions inside of container, ...), mapping HPA->GPA gets complicated. > > > > It would be better to use simple building blocks and model as: > > 2 separate backends (ram + hugetlbfs) and 2 corresponding DIMM devices. > > Right, I had forgotten that you can have cold-plugged DIMM devices. > That's a nice solution, also because it simplifies passing the GPA > configuration down to the guest. > > How would that translate to sharing HostMemoryBackend code for memory > policies? Which of Hu Tao's proposals do you like best? possible choices could be: 1: 'realize' approach I suggested drawback is: assumption that all backends derived from HostMemoryBackend will inherit NUMA controls even if backend shouldn't have one (for example: fictional remote memory backend) plus: derived types from HostMemoryBackend, don't need to know anything about NUMA. 2: #3 from Hu Tao's suggestion drawback is: every new backend have to explicitly call NUMA callbacks somewhat plus is that not NUMA aware backends could ignore NUMA callbacks, but they would still have NUMA properties available, which is confusing. 3: might be over-engineered #1 from above: build proper class hierarchy: HostMemoryBackend -> NumaMemoryBackend -> RamBackend | -> HugepageBackend |-> whatever else > > Paolo