From mboxrd@z Thu Jan 1 00:00:00 1970 From: Izik Eidus Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU Date: Sun, 12 Oct 2008 21:33:20 +0200 Message-ID: <48F25100.6040706@qumranet.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Chris Wright , Mark McLoughlin , kvm-devel , Laurent Vivier , Ryan Harper To: qemu-devel@nongnu.org Return-path: Received: from il.qumranet.com ([212.179.150.194]:34575 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943AbYJLTdZ (ORCPT ); Sun, 12 Oct 2008 15:33:25 -0400 In-Reply-To: <48F24320.9010201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.