From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id CA8B76B01B9 for ; Tue, 29 Jun 2010 11:20:13 -0400 (EDT) Date: Tue, 29 Jun 2010 10:19:37 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH 1/2] vmscan: shrink_slab() require number of lru_pages, not page order In-Reply-To: Message-ID: References: <20100625201915.8067.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Minchan Kim Cc: KOSAKI Motohiro , LKML , linux-mm , Andrew Morton , Mel Gorman , Rik van Riel , Johannes Weiner List-ID: On Sun, 27 Jun 2010, Minchan Kim wrote: > > What does the "lru_pages" parameter do in shrink_slab()? Looks > > like its only role is as a divison factor in a complex calculation of > > pages to be scanned. > > Yes. But I think it can make others confuse like this. Right. > Except zone_reclaim, lru_pages had been used for balancing slab > reclaim VS page reclaim. > So lru_page naming is a good. It is also good to make zone reclaim more deterministic by using the new counters. So I am not all opposed to the initial patch. Just clear things up a bit and make sure that this does not cause regressions because of too frequent calls to shrink_slab > So you intentionally passed order instead of the number of lru pages > for shrinking many slabs as possible as. Dont remember doing that. I suspect the parameter was renamed at some point. -- 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