From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: Windows slow boot Date: Tue, 18 Sep 2012 19:12:40 +0400 Message-ID: <50588F68.3060708@msgid.tls.msk.ru> References: <20120816104727.GA17166@alpha.arachsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Richard Davies Return-path: Received: from isrv.corpit.ru ([86.62.121.231]:32813 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758208Ab2IRPMm (ORCPT ); Tue, 18 Sep 2012 11:12:42 -0400 In-Reply-To: <20120816104727.GA17166@alpha.arachsys.com> Sender: kvm-owner@vger.kernel.org List-ID: On 16.08.2012 14:47, Richard Davies wrote: > http://marc.info/?l=qemu-devel&m=134304194329745 > > > We have been experiencing this problem for a while now too, using qemu-kvm > (currently at 1.1.1). > > Unfortunately, hv_relaxed doesn't seem to fix it. The following command line > produces the issue: > > qemu-kvm -nodefaults -m 4096 -smp 8 -cpu host,hv_relaxed -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test.img Just one question: did you try explicitly using hugepages? For that, - reserve some amount of hugepages (echo something > /proc/sys/vm/nr_hugepages), - mount hugetlbfs to somewhere, like, /dev/hugetlbfs - use -mem-path=/dev/hugetlbfs qemu option This may also reduce your lock contention. Sure, hugepages have some minus sides too, but I think it is worth to try anyway - for a single VM or for whole lot of VMs (for that you'll have to reserve much more memory after host boot). /mjt From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDzTo-0006NM-8Q for qemu-devel@nongnu.org; Tue, 18 Sep 2012 11:12:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDzTe-0004S9-Rv for qemu-devel@nongnu.org; Tue, 18 Sep 2012 11:12:52 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:58256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDzTe-0004Rq-KN for qemu-devel@nongnu.org; Tue, 18 Sep 2012 11:12:42 -0400 Message-ID: <50588F68.3060708@msgid.tls.msk.ru> Date: Tue, 18 Sep 2012 19:12:40 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <20120816104727.GA17166@alpha.arachsys.com> In-Reply-To: <20120816104727.GA17166@alpha.arachsys.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Windows slow boot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Davies Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 16.08.2012 14:47, Richard Davies wrote: > http://marc.info/?l=qemu-devel&m=134304194329745 > > > We have been experiencing this problem for a while now too, using qemu-kvm > (currently at 1.1.1). > > Unfortunately, hv_relaxed doesn't seem to fix it. The following command line > produces the issue: > > qemu-kvm -nodefaults -m 4096 -smp 8 -cpu host,hv_relaxed -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test.img Just one question: did you try explicitly using hugepages? For that, - reserve some amount of hugepages (echo something > /proc/sys/vm/nr_hugepages), - mount hugetlbfs to somewhere, like, /dev/hugetlbfs - use -mem-path=/dev/hugetlbfs qemu option This may also reduce your lock contention. Sure, hugepages have some minus sides too, but I think it is worth to try anyway - for a single VM or for whole lot of VMs (for that you'll have to reserve much more memory after host boot). /mjt