From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKF2-0004p2-NQ for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:29:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuKEw-0006ql-K0 for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:29:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKEw-0006qU-Bf for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:29:18 -0400 Message-ID: <5396EC02.7080402@redhat.com> Date: Tue, 10 Jun 2014 13:29:06 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> <20140610112321.GA24043@redhat.com> In-Reply-To: <20140610112321.GA24043@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: Yasunori Goto , Hu Tao , qemu-devel@nongnu.org, Eduardo Habkost , Igor Mammedov Il 10/06/2014 13:23, Michael S. Tsirkin ha scritto: > 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. Or TCG, or Xen. At this point, why single out KVM? (Also, "--enable-kvm -mem-path /dev/shm" works on 2.0, and it would be a regression in 2.1). >> 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". I would like to see the slowness on a real-world benchmark though. I suspect in most scenarios it would not matter. >> We should not limit ourselves due to kernel bugs. > > 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. Yes, and firefox doesn't say "no sorry can't do it" when running on such a kernel (which is much worse than more expensive TLB misses). Paolo