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

[Nick Piggin]

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?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/