From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Colp Subject: Re: [PATCH 3 of 7] xenpaging: remove srand call Date: Sat, 2 Apr 2011 12:29:33 -0700 Message-ID: References: <20110331181749.GA25674@aepfle.de> <20110401082033.GA26986@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20110401082033.GA26986@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Olaf Hering Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 1 April 2011 01:20, Olaf Hering wrote: > On Thu, Mar 31, Patrick Colp wrote: > >> Yeah, I saw that. Is it actually possible to run out of pages to >> nominate? I would think the only way this would happen is if you >> specified that 100% of the guest memory is paged out. If it is >> possible, then would it maybe be better to add a check to the random >> policy to detect when it's tried all the pages? Of course, if linear >> performs just as well (or poorly) as random, then there's no point >> changing it from what it is now. > > There is a wrap check in policy_choose_victim(). If 100% pages should be > swapped, nominate fails for a few and 100% cant be reached. I think > thats not easy to detect from within policy_choose_victim(). > I havent done any performance analysis in the policy, nor in gneral. > The performance with a linear approach is eventually better because the > loop does need to wait for a random gfn number thats still free. =C2=A0Th= e > bottleneck is likely the IO and the stopped vcpus, not testing an array > of bits. The main thing you want to reduce is the number of misses in the guest, though, rather than worrying too much about what the page-in code itself is doing. I don't really think it'll make much of a difference what way it's done (though it would be curious to know what it is). The way you've done it has the wrap check, though, which is great. Patrick > > Olaf > >