Messages in this thread | | | Date | Mon, 6 Mar 2006 09:49:09 +0200 | From | "Pekka Enberg" <> | Subject | Re: cache_reap(): Further reduction in interrupt holdoff |
| |
Hi,
(Christoph, please use penberg@cs.helsinki.fi instead.)
On 3/4/06, Christoph Lameter <clameter@engr.sgi.com> wrote: > cache_reap takes the l3->list_lock (disabling interrupts) unconditionally and > then does a few checks and maybe does some cleanup. This patch makes > cache_reap() only take the lock if there is work to do and then the lock > is taken and released for each cleaning action. > > The checking of when to do the next reaping is done without any locking > and becomes racy. Should not matter since reaping can also be skipped > if the slab mutex cannot be acquired.
The cache chain mutex is mostly used by /proc/slabinfo and not taken that often, I think. But yeah, I don't think next reaping is an issue either.
On 3/4/06, Christoph Lameter <clameter@engr.sgi.com> wrote: > The same is true for the touched processing. If we get this wrong once > in awhile then we will mistakenly clean or not clean the shared cache. > This will impact performance slightly.
Touched processing worries me little because it's used when there's high allocation pressure. Do you have any numbers where this patch helps?
Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |