Re: Avoid excessive time spend on concurrent slab shrinking

Christoph Lameter
2006-03-31T23:48:44Z

On Fri, 31 Mar 2006, Andrew Morton wrote:

> > System sluggish in general. cscope takes 20 minutes to start etc. Dropping
> > the caches restored performance.
>
> OK. What sort of system was it, and what was the workload? FIlesystem types?

A build server. Lots of scripts running, compilers etc etc.

> It's been like that for an awful long time. Can you think why this has
> only just now been noticed?

Testing has reached new level of thoroughness because of the new releases
that are due soon...

> > We just noticed general sluggishness and took some stackdumps to see what
> > the system was up to.
>
> OK. But was it D-state sleep (semaphore lock contention) or what?

Yes, lots of processes waiting on semaphores in
shrink_slab->shrink_icache_memory. Need to look at this in more detail it
seems.

I looked at the old release that worked. Seems that it did the same thing
in terms of slab shrinking. Concurrent slab shrinking was no problem. So
you may be right. Its something unrelated to the code in vmscan.c. Maybe
Nick knows something about this?