From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 1D4CC6B01F1 for ; Fri, 27 Aug 2010 04:38:16 -0400 (EDT) Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework From: Peter Zijlstra In-Reply-To: <20100827171639.83c8642c.kamezawa.hiroyu@jp.fujitsu.com> References: <1282310110.2605.976.camel@laptop> <20100825155814.25c783c7.akpm@linux-foundation.org> <20100826095857.5b821d7f.kamezawa.hiroyu@jp.fujitsu.com> <20100826115017.04f6f707.kamezawa.hiroyu@jp.fujitsu.com> <20100826124434.6089630d.kamezawa.hiroyu@jp.fujitsu.com> <20100826133028.39d731da.kamezawa.hiroyu@jp.fujitsu.com> <20100827171639.83c8642c.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Aug 2010 10:37:40 +0200 Message-ID: <1282898260.1975.1844.camel@laptop> Mime-Version: 1.0 Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki Cc: Minchan Kim , =?UTF-8?Q?Micha=C5=82?= Nazarewicz , Andrew Morton , Hans Verkuil , Daniel Walker , Russell King , Jonathan Corbet , Pawel Osciak , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, FUJITA Tomonori , linux-mm@kvack.org, Kyungmin Park , Zach Pfeffer , Mark Brown , Mel Gorman , linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Marek Szyprowski List-ID: On Fri, 2010-08-27 at 17:16 +0900, KAMEZAWA Hiroyuki wrote: > > How about changing following this? > > The thing is MAX_ORDER is static. But we want to avoid too big > > MAX_ORDER of whole zones to support devices which requires big > > allocation chunk. > > So let's add MAX_ORDER into each zone and then, each zone can have > > different max order. > > For example, while DMA[32], NORMAL, HIGHMEM can have normal size 11, > > MOVABLE zone could have a 15. > >=20 > > This approach has a big side effect? The side effect of increasing MAX_ORDER is that page allocations get more expensive since the buddy tree gets larger, yielding more splits/merges. > Hm...need to check hard coded MAX_ORDER usages...I don't think > side-effect is big. Hmm. But I think enlarging MAX_ORDER isn't an > important thing. A code which strips contiguous chunks of pages from > buddy allocator is a necessaty thing, as.. Right, once we can explicitly free the pages we want, crossing MAX_ORDER isn't too hard like you say, we can simply continue with freeing the next in order page. -- 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