Re: Avoid excessive time spend on concurrent slab shrinking

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andrew Morton wrote:

> c) go back to single-threading shrink_slab (or just shrink_icache_memory())
> 
>    For this one we'd need to understand which observations prompted Nick
>    to make shrinker_rwsem an rwsem?
> 

This was when I was looking for reasons why inode and dentry caches
would sometimes apparently explode on people and consume most of their
memory. One of the reasons was here, when slab caches did build up, and
multiple processes would start reclaim, scanning would skew away from
slab.

Considering the actual slab shrinkers are single threaded, I agree this
could cause more semaphore contention.

One thing we could do is ensure shrinker->nr gets incremented, but not
actually have more than one thread enter slab reclaim at once.

Or have the trylock&abort behaviour pushed down into the actual
shrinkers themselves, then at least we can get concurrent icache and
dcache scanning happening.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>