> 1) Active memory defragmentation
>
> I doubt anyone will deny that this is desirable. Active defragmentation will
> eliminate higher order allocation failures for non-atomic allocations, and I
> hope, generally improve the efficiency and transparency of the kernel memory
> allocator.
>
It might be just me, but this scheme sounds a bit complicated (I'm still
absorbing the other two). I find it difficult to see what happens when a
page used by a kernel pointer changes for any case other than vmalloc()
but I probably am missing something.
How about: Move order-0 allocations to slab (ignoring bootstrap issues for
now but shouldn't be hard anyway)
Each cache slab is 2^MAX_GFP_ORDER large and there is three caches
o order0-user
o order0-kreclaim
o order0-knoreclaim
order0-user is for any userspace allocation. These pages should be
trivially reclaimable with rmap available. If a large order block is
necessary, select one slab and reclaim it. This will break LRU ordering
something rotten but I am guessing that LRU ordering is not the prime
concern here. If a defrag daemon exists, scan MAX_DEFRAG_SCAN slabs and
pick the one with the most clean filesystem backed pages to chuck out
(least IO involved in reclaim).
order0-kreclaim is for kernel allocations which are trivially reclaimable
and that can be safely discared knowing that no pointer exists to them.
This is most likely to be usable for slab allocations of caches like
dentry's which can be safely thrown out. A quick look of /proc/slabinfo
shows that most slabs are just 1 page large. Slabs already have a
set_shrinker() callback for the removal of objects so it is likely that
this could be extended for telling caches to clear all objects and discard
a particular slab.
order0-knoreclaim is for kernel allocations which cannot be easily
reclaimed and have pointers to the allocation which are difficult to
reclaim. For all intents and purposes, these are not reclaimable without
impementing swapping in kernel space.
This has a couple of things going for it
o Reclaimable pages are in easy to search globs
o Gets nifty per-cpu alloc and caching that comes with slab automatically
o Freeing high order pages is a case of discarding pages in one slab
o Doesn't require fancy pants updating of pointers or page tables
o Possible ditch the mempool interface as slab already has similar functionality
o Seems simple
Opinions?
-- Mel Gorman - 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/
This archive was generated by hypermail 2b29 : Mon Jun 30 2003 - 22:00:18 EST