> [...] (buddy together with directed swap-out would obviously be
> better, but directed page-outs are hard).
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:
if ( is_free(pte_2_phys(pte)-PAGE_SIZE) ||
is_free(pte_2_phys(pte)+PAGE_SIZE))
page_out_pte(pte);
else
if (need_more_single_pages())
page_out_pte(pte);
[it's not exactly like this because we also have to check for alignment,
but anyway] [the above code is hackish because it hard-codes 8k
allocations, but it can be extended to N-order too]
the probability of 'getting it right' by picking a random pte only depends
on the ratio of free_pages/total_pages. If we keep 20% free pages, we will
iterate ~5 times before having found a 'proper' pte. Since we will do a
swapout/sleep anyway, this is not really a problem. Also, we will always
first try to keep the 20% ratio before doing an 'excessive search' for
proper 8k pages due to the else branch.
the number of iterations needed to satisfy higher-order (16k) goals
increases exponentially, fortunately the need for such allocations
decreases exponentially too ;)
[it's true that with direct phys->virtual mappings we would be able to do
a single step to 'extend' a single-free-page to a dual page, but it's
really not that bad in the 'blind' case. 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.]
[unswappable pages disturb the mechanizm again, but we have this problem
with all allocation schemes]
[another problem is shared pages, but i think it only increases the number
of 'iterations' needed to reach the goal, it does not prevent the
mechanizm]
[btw, the above scheme is a quite naive but already more or less complete
implementation of the 'fully-vectorized' VM.]
-- 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