From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKKg-0007sF-Rb for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:35:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuKKa-0000oF-HV for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:35:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKKa-0000mg-8z for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:35:08 -0400 Date: Tue, 10 Jun 2014 14:35:28 +0300 From: "Michael S. Tsirkin" Message-ID: <20140610113528.GB26794@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> <20140610112321.GA24043@redhat.com> <5396EC02.7080402@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5396EC02.7080402@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:29:06PM +0200, Paolo Bonzini wrote: > 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). It prints fprintf(stderr, "Warning: path not on HugeTLBFS: %s\n", path); Correct? I guess I agree then, hopefully the warning is enough. Maybe add an extra warning that performance will suffer. > >>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. Weird. Things like kernel build time are known to be measureably improved by using THP. > >>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 kernel can't speed up fsync. So IIRC instead, firefox switched to using renames instead of fsync. IMHO QEMU should do the same, look for a mechanism that kernel can support efficiently, instead of insisting on using a feature that it can't. -- MST