From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKSs-0001Iz-Ie for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:43:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuKSl-0003Pz-Km for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:43:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuKSl-0003Pi-AV for qemu-devel@nongnu.org; Tue, 10 Jun 2014 07:43:35 -0400 Message-ID: <5396EF5F.2050602@redhat.com> Date: Tue, 10 Jun 2014 13:43:27 +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> <5396EC02.7080402@redhat.com> <20140610113528.GB26794@redhat.com> In-Reply-To: <20140610113528.GB26794@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: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