Re: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat

[Nick Piggin <nickpiggin@yahoo.com.au>]

Linus Torvalds wrote:

>
>On Sun, 5 Sep 2004, Arjan van de Ven wrote:
>
>>well... we have a reverse mapping now. What is stopping us from doing
>>physical defragmentation ?
>>
>
>Nothing but replacement policy, really, and the fact that not everything
>is rmappable.
>
>I think we should _normally_ honor replacement policy, the way we do now.  
>Only if we are in the situation "we have enough memory, but not enough
>high-order-pages" should we go to a separate physical defrag algorithm.
>
>

Sure.

>So either kswapd should have a totally different mode, or there should be
>a separate "kdefragd". It would potentially also be good if it is user-
>triggerable, so that you could, for example, have a heavier defragd run
>from the daily "cron" runs - something that doesn't seem to make much
>sense from a traditional kswapd standpoint.
>
>In other words, I don't think the physical thing should be triggered at 
>all by normal memory pressure. A large-order allocation failure would 
>trigger it "somewhat", and maybe it might run very slowly in the 
>background (wake up every five minutes or so to see if it is worth doing 
>anything), and then some user-triggerable way to make it more aggressive.
>
>Does that sound sane to people?
>
>

Not to me :P

I think doing it just in time with kswapd and watermarks like we
do for order 0 allocations should be fine.

If you think of kswapd as "do the same freeing work the allocator
will otherwise have to" and "provide a context for doing freeing
work if the allocator can't" (in the !wait case)... then I think my
changes are pretty logical.

I think I confused everybody in the first email - we *do not* try
to heed any order-3 and above watermarks if we're only doing order-2
and below allocations... maybe this was the sticking point?