From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKXF-00052W-SQ for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:48:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuKX9-0005CW-7l for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:48:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKX8-0005CO-UO for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:48:07 -0400 Date: Tue, 10 Jun 2014 14:48:28 +0300 From: "Michael S. Tsirkin" Message-ID: <20140610114828.GA27056@redhat.com> References: <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> <20140610113528.GB26794@redhat.com> <5396EF5F.2050602@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5396EF5F.2050602@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:43:27PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 13:35, Michael S. Tsirkin ha scritto: > >>>>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? > > Yes. > > >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. > > Even measurable speedups in most scenarios would not matter. I don't care > if a kernel compile takes 2 minutes vs. 110 seconds (for a 10% speedup), > even though it's great that THP can speed up such a common task. > > Paolo True. But I am not sure why would such a user play with vhost-user at all. That one seems to mostly be about using aggressive polling to drive down guest to guest latency. -- MST