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

[Patrick Colp <pjcolp@cs.ubc.ca>]

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