WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

On 1 April 2011 01:20, Olaf Hering <olaf@xxxxxxxxx> 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.  The
> 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
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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