[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2.5.33-mm1
William Lee Irwin III wrote:
>> It also looks like there's either a bit of internal fragmentation or a
>> missing kmem_cache_reap() somewhere:
>> ext3_inode_cache: 20001KB 51317KB 38.97
>> dentry_cache: 4734KB 18551KB 25.52
>> radix_tree_node: 1811KB 1923KB 94.20
>> buffer_head: 1132KB 1378KB 82.12
On Tue, Sep 03, 2002 at 06:13:17PM -0700, Andrew Morton wrote:
> That's really outside the control of slablru. It's determined
> by the cache-specific LRU algorithms, and the allocation order.
> You'll need to look at the second-last and third-last columns in
> /proc/slabinfo (boy I wish that thing had a heading line, or a nice
> program to interpret it):
> ext3_inode_cache 959 2430 448 264 270 1
> That's 264 pages in use, 270 total. If there's a persistent gap between
> these then there is a problem - could well be that slablru is not locating
> the pages which were liberated by the pruning sufficiently quickly.
> Calling kmem_cache_reap() after running the pruners will fix that up.
# grep ext3_inode_cache /proc/slabinfo
ext3_inode_cache 18917 87012 448 7686 9668 1
...
ext3_inode_cache: 8098KB 38052KB 21.28
Looks like a persistent gap from here.
Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/