From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuK8y-00032a-Gg for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:23:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuK8q-00049G-Tl for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:23:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuK8q-000493-KL for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:23:00 -0400 Date: Tue, 10 Jun 2014 14:23:21 +0300 From: "Michael S. Tsirkin" Message-ID: <20140610112321.GA24043@redhat.com> References: <988dc97c3b3e3c89066b3b3dc8c17b3fccc3c816.1402299637.git.hutao@cn.fujitsu.com> <20140609133246.286d749c@thinkpad> <20140610020021.GD29724@G08FNSTD100614.fnst.cn.fujitsu.com> <480968011.20454430.1402376972892.JavaMail.zimbra@redhat.com> <20140610083006.GA12425@G08FNSTD100614.fnst.cn.fujitsu.com> <5396C84A.8030202@redhat.com> <20140610095945.GH7423@redhat.com> <5396E804.9090401@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5396E804.9090401@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 18/29] hostmem: add file-based HostMemoryBackend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Yasunori Goto , Hu Tao , qemu-devel@nongnu.org, Eduardo Habkost , Igor Mammedov On Tue, Jun 10, 2014 at 01:12:04PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 11:59, Michael S. Tsirkin ha scritto: > >> >What's the point compared to memory-backend-ram? > >> > >> That you can use shared memory, for example together with vhost-user. > > > >I don't think it's a good idea until THP supports shared memory. > > Why? For example it would be useful for testing on machines that you don't > have root for, and that do not have a hugetlbfs mount point. For example > you could run the test case from the vhost-user's patches. Sounds useful, I guess we could allow this when running under qtest. > THP is not a magic wand and you can get slowness from memory fragmentation > at any time. Right but there's a difference between "can get slowness when memory is overcommitted" and "will get slowness even on a mostly idle box". > We should not limit ourselves due to kernel bugs. > > Paolo Why not? Practically people do have to run this on some kernel, we should not use kernel in a way that it can't support well. Old firefox doing a ton of fsync commands and slowing the box to a crawl comes to mind as another example of this. -- MST