From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id E20F66B004A for ; Wed, 6 Oct 2010 12:49:41 -0400 (EDT) Date: Wed, 6 Oct 2010 11:49:38 -0500 (CDT) From: Christoph Lameter Subject: Re: [UnifiedV4 00/16] The Unified slab allocator (V4) In-Reply-To: <20101006164326.GB17987@basil.fritz.box> Message-ID: References: <20101005185725.088808842@linux.com> <87fwwjha2u.fsf@basil.nowhere.org> <20101006162547.GA17987@basil.fritz.box> <20101006164326.GB17987@basil.fritz.box> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Andi Kleen Cc: Pekka Enberg , linux-mm@kvack.org List-ID: On Wed, 6 Oct 2010, Andi Kleen wrote: > > > So it would depend on that total number of caches in the system? > > > > Yes. Also the expiration is triggerable from user space. You can set up a > > cron job that triggers cache expiration every minute or so. > > movement also. > > That doesn't seem like a good way to do this to me. Such things should work > without special cron jobs. Its trivial to add a 2 second timer (or another variant) if we want the exact slab cleanup behavior. However, then you have the disturbances again of running code by checking all the caches in the system on all cpus. Running the cleaning from reclaim avoids that. -- 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: email@kvack.org