From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759505AbXHBSgA (ORCPT ); Thu, 2 Aug 2007 14:36:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756661AbXHBSfw (ORCPT ); Thu, 2 Aug 2007 14:35:52 -0400 Received: from canuck.infradead.org ([209.217.80.40]:52617 "EHLO canuck.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756495AbXHBSfv (ORCPT ); Thu, 2 Aug 2007 14:35:51 -0400 Subject: Re: [PATCH 0/2] Synchronous Lumpy Reclaim V3 From: Peter Zijlstra To: Andy Whitcroft Cc: Andrew Morton , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 02 Aug 2007 20:35:10 +0200 Message-Id: <1186079710.11797.12.camel@lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2007-08-02 at 19:17 +0100, Andy Whitcroft wrote: > [This is a re-spin based on feedback from akpm.] > > As pointed out by Mel when reclaim is applied at higher orders a > significant amount of IO may be started. As this takes finite time > to drain reclaim will consider more areas than ultimatly needed > to satisfy the request. This leads to more reclaim than strictly > required and reduced success rates. > > I was able to confirm Mel's test results on systems locally. > These show that even under light load the success rates drop off far > more than expected. Testing with a modified version of his patch > (which follows) I was able to allocate almost all of ZONE_MOVABLE > with a near idle system. I ran 5 test passes sequentially following > system boot (the system has 29 hugepages in ZONE_MOVABLE): > > 2.6.23-rc1 11 8 6 7 7 > sync_lumpy 28 28 29 29 26 > > These show that although hugely better than the near 0% success > normally expected we can only allocate about a 1/4 of the zone. > Using synchronous reclaim for these allocations we get close to 100% > as expected. > > I have also run our standard high order tests and these show no > regressions in allocation success rates at rest, and some significant > improvements under load. > > Following this email are two patches, both should be considered as > bug fixes to lumpy reclaim for 2.6.23: > > ensure-we-count-pages-transitioning-inactive-via-clear_active_flags: > this a bug fix for Lumpy Reclaim fixing up a bug in VM Event > accounting when it marks pages inactive, and > > Wait-for-page-writeback-when-directly-reclaiming-contiguous-areas: > updates reclaim making direct reclaim synchronous when applied > at orders above PAGE_ALLOC_COSTLY_ORDER. > > Patches against 2.6.23-rc1. Andrew please consider for -mm and > for pushing to mainline. Acked-by: Peter Zijlstra