From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60091)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1YJNdj-0006nc-4Z
	for qemu-devel@nongnu.org; Thu, 05 Feb 2015 09:42:44 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1YJNdb-0007n2-EV
	for qemu-devel@nongnu.org; Thu, 05 Feb 2015 09:42:43 -0500
Received: from smtp3.mundo-r.com ([212.51.32.191]:18649 helo=smtp4.mundo-r.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1YJNdb-0007kP-8u
	for qemu-devel@nongnu.org; Thu, 05 Feb 2015 09:42:35 -0500
Date: Thu, 5 Feb 2015 15:42:28 +0100
From: Alberto Garcia <berto@igalia.com>
Message-ID: <20150205144228.GA13117@igalia.com>
References: <1423140931-11823-1-git-send-email-berto@igalia.com>
	<54D374AE.2090500@redhat.com> <20150205135934.GA18629@igalia.com>
	<20150205141719.GC4666@noname.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150205141719.GC4666@noname.redhat.com>
Subject: Re: [Qemu-devel] [PATCH] block: Give always priority to unused
 entries in the qcow2 L2 cache
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, Max Reitz <mreitz@redhat.com>

On Thu, Feb 05, 2015 at 03:17:19PM +0100, Kevin Wolf wrote:

> > By never allowing the hit count to go down to zero, we make sure
> > that all unused entries are chosen first before a valid one is
> > discarded.
> 
> But does this actually improve a lot? cache_hits is only 0 for the
> first few accesses and it never becomes 0 again after that. The
> result might be that soon all the entries have cache_hits == 1, and
> we get the same problem as you're describing - only the first few
> entries will be reused.

I targeted the specific case where the size of the L2 cache is set so
that it's big enough for the whole disk.

I have a setup with a 16GB disk image and a 2MB L2 cache (that's 32
entries). If I do random rw, after two minutes I get an average of 3K
IOPS, and more than half (19) of the cache entries are still unused.

With the patch the cache fills up immediately and I get sustained ~20K
IOPS from the very beginning.

Berto