From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: *terrible* speed of savevm/loadvm/delvm Date: Thu, 13 Nov 2008 14:33:16 +0200 Message-ID: <491C1E8C.3070701@redhat.com> References: <491B0F4B.9060502@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list To: Michael Tokarev Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40462 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752066AbYKMMd3 (ORCPT ); Thu, 13 Nov 2008 07:33:29 -0500 In-Reply-To: <491B0F4B.9060502@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: Michael Tokarev wrote: > Somewhere between kvm-75 and kvm-78, the > mentioned commands has been slowed down > to insane levels. By "insane" I mean to > take about 10 minutes(!) to save/load a > 128MB RAM/1GB HDD VM's state. It used > to require several seconds for much larger > VMs... > > Here's a typical sequence of system calls > during savevm: [snip strace] > As you see, it writes 2 bytes, llseeks to THE SAME > position, writes next 2 bytes and so on. This takes > HUGE amount of time, and can be done, in most cases, > in a single write without any seeks. > > Is it just me or are savevm/loadvm/delvm really THAT > broken? It's qcow2 that is broken, with the new default cache=writethrough. Does cache=writeback speed things up? This is probably block reference counts being updated. There were some batching patches posted, but they have not been applied yet, and are probably insufficient for savevm. > And since migration to disk has been removed too, > there's no way currently to save the VM state... That's being restored. -- error compiling committee.c: too many arguments to function