Re: [PATCH]: Option to run cache reap in thread mode
From: Manfred Spraul
Date: Fri Jun 18 2004 - 16:53:02 EST
Andrew Morton wrote:
Dimitri Sivanich <sivanich@xxxxxxx> wrote:
At the time of the holdoff (the point where we've spent a total of 30 usec in
the timer_interrupt), we've looped through more than 100 of the 131 caches,
usually closer to 120.
ahh, ooh, ow, of course.
Manfred, we need a separate list of "slabs which might need reaping".
A cache that might need reaping is a cache that has seen at least one
kmem_cache_free(). The list would trade less time in the timer context
at the expense of slower kmem_cache_free calls. I'm fairly certain that
this would be end up as a big net loss.
That'll help the average case. To help the worst case we should change
cache_reap() to only reap (say) ten caches from the head of the new list
and to then return.
I'll write something:
- allow to disable the DMA kmalloc caches for archs that do not need them.
- increase the timer frequency and scan only a few caches in each timer.
- perhaps a quicker test for cache_reap to notice that nothing needs to
be done. Right now four tests are done (!flags & _NO_REAP,
ac->touched==0, ac->avail != 0, global timer not yet expired). It's
possible to skip some tests. e.g. move the _NO_REAP caches on a separate
list, replace the time_after(.next_reap,jiffies) with a separate timer.
--
Manfred
-
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/