Re: [PATCH]: Option to run cache reap in thread mode

[Dimitri Sivanich]

On Wed, Jun 16, 2004 at 07:23:49PM +0200, Manfred Spraul wrote:
> Dimitri wrote:
> 
> >In the process of testing per/cpu interrupt response times and CPU 
> >availability,
> >I've found that running cache_reap() as a timer as is done currently 
> >results
> >in some fairly long CPU holdoffs.
> >
> What is fairly long?
Into the 100's of usec.  I consider anything over 30 usec too long.
I've seen this take longer than 30usec on a small (8p) system.

> If cache_reap() is slow than the caches are too large.
> Could you limit cachep->free_limit and check if that helps? It's right 
> now scaled by num_online_cpus() - that's probably too much. It's 
> unlikely that all 500 cpus will try to refill their cpu arrays at the 
> same time. Something like a logarithmic increase should be sufficient.

I haven't tried this yet, but I'm even seeing this on 4 cpu systems.

> Do you use the default batchcount values or have you increased the values?

Default.

> I think the sgi ia64 system do not work with slab debugging, but please 
> check that debugging is off. Debug enabled is slow.

# CONFIG_DEBUG_SLAB is not set

> 
> --
>    Manfred

Dimitri Sivanich <sivanich@xxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/