Re: Avoid excessive time spend on concurrent slab shrinking

[Andrew Morton <akpm@osdl.org>]

Christoph Lameter <clameter@sgi.com> wrote:
>
> 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.

Interesting.    Many CPUs?

> > 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.

Please.  Or at least suggest a means-of-reproducing.

A plain old sysrq-T would be great.  That'll tell us who owns iprune_sem,
and what he's up to while holding it.  Actually five-odd sysrq-T's would be
better.

If the lock holder is stuck on disk I/O or a congested queue or something
then that's very different from the lock holder being in a
pointlessly-burn-CPU-scanning-stuff condition.

> 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?

--
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>