From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbUMF-0000kU-9m for qemu-devel@nongnu.org; Mon, 04 Jun 2012 06:18:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbUM9-0001Mz-Jk for qemu-devel@nongnu.org; Mon, 04 Jun 2012 06:17:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbUM9-0001Ml-Bq for qemu-devel@nongnu.org; Mon, 04 Jun 2012 06:17:49 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q54AHmj3027900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Jun 2012 06:17:48 -0400 Message-ID: <4FCC8B49.30908@redhat.com> Date: Mon, 04 Jun 2012 12:17:45 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1337703438-9764-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1337703438-9764-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1.2 0/7] Manual writethrough cache and cache mode toggle List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org Am 22.05.2012 18:17, schrieb Paolo Bonzini: > This is an alternative implementation of writethrough caching. By always > opening protocols in writethrough mode and doing flushes manually after > every write, it achieves two results: 1) it makes flipping the cache mode > extremely easy; 2) it lets formats control flushes during metadata updates > even in writethrough mode, which makes the updates more efficient; 3) > it makes cache=writethrough automatically flush metadata without needing > extra work in the formats. > > In practice, the performance result is a wash. I measured "make -j3 > vmlinux" on a 2-core guest/4-core host, with 2GB memory in the guest > and 8GB in the host. > > Performance was measured starting qemu-kvm with an empty qcow2 image, > a virtio disk and cache=writethrough (F16 installation + exploded kernel > tarball in the backing file), and the results are as follows: > > without patch: > real 9m22.416s user 12m8.955s sys 3m46.331s > real 9m21.602s user 12m20.124s sys 3m51.126s > real 9m22.258s user 12m14.900s sys 3m48.595s > > with patch: > real 9m17.617s user 12m16.837s sys 3m48.637s > real 9m18.926s user 12m20.083s sys 3m50.458s > real 9m15.751s user 12m41.944s sys 3m56.447s > > Unlike the RFC, this is tested exactly with these seven patches. The RFC > was tested with follow-up cleanups that hid the problem in patch 3. > > v1->v2: only patch 3 changed, was completely backwards in v1 Are you going to send a v3 for patches 3 and possibly 5/6? Kevin