Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751316AbWBWSsK (ORCPT ); Thu, 23 Feb 2006 13:48:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751373AbWBWSsK (ORCPT ); Thu, 23 Feb 2006 13:48:10 -0500 Received: from omx2-ext.sgi.com ([192.48.171.19]:4741 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1751316AbWBWSsJ (ORCPT ); Thu, 23 Feb 2006 13:48:09 -0500 Date: Thu, 23 Feb 2006 10:47:53 -0800 (PST) From: Christoph Lameter To: Pekka Enberg cc: Christoph Lameter , Andrew Morton , Alok Kataria , manfred@colorfullife.com, linux-kernel@vger.kernel.org Subject: Re: slab: Remove SLAB_NO_REAP option In-Reply-To: <1140719812.11455.1.camel@localhost> Message-ID: References: <20060223020957.478d4cc1.akpm@osdl.org> <1140719812.11455.1.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 846 Lines: 24 On Thu, 23 Feb 2006, Pekka Enberg wrote: > Look at the loop, it is redundant work (like acquiring/releasing a > spinlock). The cache_cache is practically static, which is why it makes > sense to leave it alone. There is a loop but its broken by p = l3->slabs_free.next; if (p == &(l3->slabs_free)) break; One cache_reap() may scan the free list but once its free the code is skipped. There are potentially large amounts of other caches around that are also basically static and which also would need any bypass that we may implement. - 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/