From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <457EAB38.2020506@shadowen.org> Date: Tue, 12 Dec 2006 13:14:32 +0000 From: Andy Whitcroft MIME-Version: 1.0 Subject: Re: [PATCH 0/4] Lumpy Reclaim V3 References: <20061212031312.e4c91778.akpm@osdl.org> In-Reply-To: <20061212031312.e4c91778.akpm@osdl.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: linux-mm@kvack.org, Peter Zijlstra , Mel Gorman , linux-kernel@vger.kernel.org List-ID: Andrew Morton wrote: > On Wed, 6 Dec 2006 16:59:04 +0000 > Andy Whitcroft wrote: > >> This is a repost of the lumpy reclaim patch set. > > more... > > One concern is that when the code goes to reclaim a lump and fails, we end > up reclaiming a number of pages which we didn't really want to reclaim. > Regardless of the LRU status of those pages. > > I think what we should do here is to add the appropriate vmstat counters > for us to be able to assess the frequency of this occurring, then throw a > spread of workloads at it. If that work indicates that there's a problem > then we should look at being a bit smarter about whether all the pages look > to be reclaimable and if not, restore them all and give up. > > Also, I suspect it would be cleaner and faster to pass the `active' flag > into isolate_lru_pages(), rather than calculating it on the fly. And I > don't think we need to calculate it on every pass through the loop? > > > We really do need those vmstat counters to let us see how effective this > thing is being. Basic success/fail stuff. Per-zone, I guess. Sounds like a cue ... I'll go do that. -apw -- 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