... I would say that I haven't overlooked it :-)
shrink_mmap is the function which looks on any physical
page in physical order ... no vm magic is needed.
> Furthermore, as long as kswapd succeeds in freeing a page
> with a certain method (eg. shrink_mmap) it will keep calling
> that method until it fails.
> This means that shrink_mmap will always try to free the next
> page when it succeeds in freeing the page.
Hmmm ... there is a upper limit (ORDER_LVL) of 4 contiuous
pages and no one more ... I hope.
Clear it's not perfect ... it's just an idea for pushing
on the development memory defragmentation of before 2.2 is
out there.
My approach is not an active defragmentation by moving pages
around ... its simply increases the possibility of getting free
pages in continuous order ... the reordering of the free_area
struct of free pages should be done in page_alloc.c.
> Your patch will add nothing to memory defragmentation, and
> AFAIK it won't even have the effect of overly reducing the
> number of cached pages.
>
> Nevertheless, it was a nice try.
Maybe I'm missed something ... but the free page algorithm
should handel/reorder 4 continuous free pages, shouldn't it.
My approach is a try to get `the foot into the door' :-))
Werner