Messages in this thread |  | | Date | Thu, 06 Sep 2001 14:21:14 +0100 | From | Alex Bligh - linux-kernel <> | Subject | Re: page pre-swapping + moving it on cache-list |
| |
Stephan / Rik,
--On Thursday, September 06, 2001 10:05 AM -0300 Rik van Riel <riel@conectiva.com.br> wrote:
> Pages on the inactive_clean list contain data. Throwing > away data when you can keep it in memory isn't the smartest > thing. > >> Besides the fact, that the splitting in two lists prevents proper >> defragmentation > > Patches to fix this thing while still allowing us to keep > the data in memory for most pages are appreciated.
It's not keeping it two lists that prevents proper defragmentation. It's having it allocated all around memory, and never freeing the pages which prevent coalescence of areas, and thus either throwing away the data, or garbage collecting, that prevents defragmentation. We never free these pages either because they sit in an idle system (with no memory pressure) in places like inactive_dirty, or in caches, or, in an active system, because they are direct_reclaim'd out of inactive_clean etc., so never get freed [1].
As this kind of garbage collection requires memcpy() etc., it might be harmless when the system is idle, but isn't going to be an attractive option when the system is busy thrashing away (though it might be possible to hueristically evict awkward pages preferentially, by aging them more harshly).
But before we go introducing tentacles of the buddy system into every part of the memory manager, I'd like to be satisfied we can't attempt to allocate and free stuff more intelligently in the first place.
I have some more ideas on this I shall code up tonight.
[1] though as disabling direct_reclaim entirely has NO measurable effect on fragmentation, fixing it is at best a necessary but not sufficient component of a fix). I haven't measured the effect of Roger L's patch in total.
-- Alex Bligh - 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/
|  |