From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kp6h0-000240-7c
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 15:33:30 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kp6gy-00022l-0x
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 15:33:29 -0400
Received: from [199.232.76.173] (port=38377 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kp6gx-00022i-Qx
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 15:33:27 -0400
Received: from il.qumranet.com ([212.179.150.194]:34588)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <izik@qumranet.com>) id 1Kp6gx-0003DP-D4
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 15:33:27 -0400
Message-ID: <48F25100.6040706@qumranet.com>
Date: Sun, 12 Oct 2008 21:33:20 +0200
From: Izik Eidus <izik@qumranet.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
References: <48EE38B9.2050106@codemonkey.ws>	<48EF1D55.7060307@redhat.com>	<48F0E83E.2000907@redhat.com>	<48F10DFD.40505@codemonkey.ws>	<20081012004401.GA9763@acer.localdomain>	<48F1CF9E.9030500@redhat.com>
	<48F23AF1.2000104@codemonkey.ws> <48F24320.9010201@redhat.com>
In-Reply-To: <48F24320.9010201@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, kvm-devel <kvm@vger.kernel.org>, Laurent Vivier <Laurent.Vivier@bull.net>, Ryan Harper <ryanh@us.ibm.com>

Avi Kivity wrote:
>
> LRU typically makes fairly bad decisions since it throws most of the
> information it has away.  I recommend looking up LRU-K and similar
> algorithms, just to get a feel for this; it is basically the simplest
> possible algorithm short of random selection.
>
> Note that Linux doesn't even have an LRU; it has to approximate since it
> can't sample all of the pages all of the time.  With a hypervisor that
> uses Intel's EPT, it's even worse since we don't have an accessed bit.
> On silly benchmarks that just exercise the disk and touch no memory, and
> if you tune the host very aggresively, LRU will win on long running
> guests since it will eventually page out all unused guest memory (with
> Linux guests, it will never even page guest memory in).  On real life
> applications I don't think there is much chance.
>
>   
But when using O_DIRECT you actuality make the pages not swappable at all...
or am i wrong?
maybe somekind of combination with the mm shrink could be good,
do_try_to_free_pages is good point for reference.