From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH 3 of 7] xenpaging: remove srand call Date: Fri, 1 Apr 2011 10:20:33 +0200 Message-ID: <20110401082033.GA26986@aepfle.de> References: <20110331181749.GA25674@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Patrick Colp Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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. The bottleneck is likely the IO and the stopped vcpus, not testing an array of bits. Olaf