HI Kingsley
You wrote:
>
> If you are having slab memory problems or
> dcache/icache get too large and seen not to be
> pruned 'correctly' - This patch may well help.
>
> and
>
> Feedback very welcome
>
> Can you elaborate on what:
>
> slab memory problems and
>
> dcache/icache
>
> getting too large and
> not being pruned 'correctly'
>
> look like to an end user?
Without slablru on a lightly loaded box you would see memory 'disappear'
ie. vmstat would show the free/buf/cache numbers decreasing. If you
then looked at /proc/slabinfo you would see some caches (usually inode
and dentry) using lots of memory. This memory eventually will get reclaimed
when we get vm pressure. With out slablru this pressure comes too late
and is often caused by slab caches instead of real world loads...
What slablru does basicly is sync the shrinking of slab caches with the
rest of the vm. So if you allocate lots of slab pages (like during an updatedb
run) the vm takes this into account and even with low vm pressure starts
trimming caches. This means that, while slab caches can still get large, the
vm will trim them at the same rate it does other pages. It no longer waits
until too long to do so.
One small detail in slablru. There are currently two types of slab caches.
Those that free slabs directly and those that age their slabs before freeing
them. The dcache (dentries) and inode caches age their members. This
also contributed to the above problem. The stock kernel ages and
shrinks at the same time. slablru factors out aging and shrinking. This
helps keep these caches using their fair share (which can be large) of
the systems resources.
Ed Tomlinson
-
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 : Thu Aug 15 2002 - 22:00:22 EST