This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 3 of 7] xenpaging: remove srand call

To: Patrick Colp <pjcolp@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3 of 7] xenpaging: remove srand call
From: Olaf Hering <olaf@xxxxxxxxx>
Date: Fri, 1 Apr 2011 10:20:33 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 01 Apr 2011 01:21:26 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1301646034; l=1002; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=ZBzGNOzJvBfod1JFlhzTnUSPODs=; b=LpOUtyFD9lJKUV9f3US7MZg65ysQd47r6ZpDwWw5uqqTzJv4muM12PqYX4bL3aX4LRy kLOYGcK4yEHqQk4yvEN6sPkLX6eD7G7y8wgJVx6H3iO8IJQiGzOu03AC1SO+g6Iz5IJPf rQuYJAMEAU3J64pRX/42yQgLVW+KVmKHJ8Y=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTikB-OcCH=oM+rPw4vKw2hLnMz8iUFLkUBxW9=VX@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1301592977@localhost> <cd35892de8ff2388aa46.1301592980@localhost> <AANLkTikuR1S0bkYshBC7sWY_L8Gz1Oi+Q3vN3J1s=1dZ@xxxxxxxxxxxxxx> <20110331181749.GA25674@xxxxxxxxx> <AANLkTikB-OcCH=oM+rPw4vKw2hLnMz8iUFLkUBxW9=VX@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>