Messages in this thread | | | Date | Mon, 06 Sep 2004 11:35:07 +1000 | From | Nick Piggin <> | Subject | Re: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |