Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755508Ab0KIVur (ORCPT ); Tue, 9 Nov 2010 16:50:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12189 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755458Ab0KIVue (ORCPT ); Tue, 9 Nov 2010 16:50:34 -0500 Date: Tue, 9 Nov 2010 22:49:14 +0100 From: Andrea Arcangeli To: KOSAKI Motohiro Cc: linux-mm@kvack.org, Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Hugh Dickins , Rik van Riel , Mel Gorman , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Christoph Lameter , Chris Wright , bpicco@redhat.com, Balbir Singh , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura , Chris Mason , Borislav Petkov Subject: Re: [PATCH 61 of 66] use compaction for GFP_ATOMIC order > 0 Message-ID: <20101109214914.GF6809@random.random> References: <20101109151440.BC75.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101109151440.BC75.A69D9226@jp.fujitsu.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2543 Lines: 52 On Tue, Nov 09, 2010 at 07:27:37PM +0900, KOSAKI Motohiro wrote: > > From: Andrea Arcangeli > > > > This takes advantage of memory compaction to properly generate pages of order > > > 0 if regular page reclaim fails and priority level becomes more severe and we > > don't reach the proper watermarks. > > > > Signed-off-by: Andrea Arcangeli > > First, I don't think this patch is related to GFP_ATOMIC. So, I think the > patch title is a bit misleading. > > Second, this patch has two changes. 1) remove PAGE_ALLOC_COSTLY_ORDER > threshold 2) implement background compaction. please separate them. Well the subject isn't entirely misleading: background compaction in kswapd is only for the GFP_ATOMIC so GFP_ATOMIC order >0 allocations are definitely related to this patch. Then I ended up then allowing compaction for all order of allocations as it doesn't make sense to fail order 2 for the kernel stack and succeed order 9 but it's true I can split that off, I will split it for #33, thanks for allowing me to clean up the stuff better. > Third, This patch makes a lot of PFN order page scan and churn LRU > aggressively. I'm not sure this aggressive lru shuffling is safe and > works effective. I hope you provide some demonstration and/or show > benchmark result. The patch will increase the amount of compaction for GFP_ATOMIC order >0, but it won't alter the amount of free pages in the system, but it'll satisfy the in-function-of order watermarks that are right now ignored. If user asked GFP_ATOMIC order > 0, this is what it asks, it's up to the user not to ask for it if it's not worthwhile. If user doesn't want this but it just wants to poll the LRU it should use GFP_ATOMIC|__GFP_NO_KSWAPD. The benchmark results I don't have at the moment but this has been tested with tg3 with jumbo packets that trigger order 2 allocation and no degradation was noticed. To be fair it didn't significantly improve the amount of order 2 (9046 bytes large skb) allocated from irq though, but I thought it was good idea to keep it in case there are less aggressive/frequent users doing similar things. Overall the more important part of the patch is the point 2) that I can make it cleaner by splitting it off as you noticed and I will do it. -- 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/