> > why are they hard? We currently pretty blindly walk a process's VM to find
> > (single) swappable pages, and kick the swapout casually. To 'be aware' of
> > proper 8k physical pages we have to do something like this:
>
> But we'd like to be able to get larger areas than just 8kB, right?
yes but:
<<
the number of iterations needed to satisfy higher-order (16k) goals
increases exponentially, fortunately the need for such allocations
decreases exponentially too ;)
>>
and:
<<
[...] We throw more CPU power on a
problem where we swap like mad anyway. There is no theoretical difference
between the two solutions, reverse page tables cache the mappings at the
cost of more allocated memory and higher mm-handling CPU cost, 'blind
walking' uses less memory but uses more CPU in the 'lets swap' case.
>>
so we throw _another_ resource on the problem, not the same resource.
(reverse page tables save CPU power, at the expense of memory)
are there any 16k allocations needed in RL? We need ~25 iterations to get
a proper 16k-goal swapout. Also, this is _worst case_, when the system
gets 'out of balance'. An NFS server doing a static rate of 16k
allocations/deallocations will keep the 16k pool properly populated. We
get only this worst-case scenario when we get out of balance. (which
probably means hard trashing anyway for a couple of minutes, so spending
CPU cycles to get it right does not seem to be a bad move)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html