From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with SMTP id 73A7A6B01F3 for ; Tue, 30 Mar 2010 12:45:38 -0400 (EDT) Date: Tue, 30 Mar 2010 18:44:38 +0200 From: Andrea Arcangeli Subject: Re: [PATCH 36 of 41] remove PG_buddy Message-ID: <20100330164438.GI5825@random.random> References: <27d13ddf7c8f7ca03652.1269887869@v2.random> <1269888584.12097.371.camel@laptop> <20100329221718.GA5825@random.random> <1269901837.9160.43341.camel@nimitz> <20100330001511.GB5825@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: Dave Hansen , Peter Zijlstra , linux-mm@kvack.org, Andrew Morton , Marcelo Tosatti , Adam Litke , Avi Kivity , Izik Eidus , Hugh Dickins , Nick Piggin , Rik van Riel , Mel Gorman , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann , "Michael S. Tsirkin" , Johannes Weiner , Daisuke Nishimura List-ID: On Tue, Mar 30, 2010 at 11:35:01AM -0500, Christoph Lameter wrote: > On Tue, 30 Mar 2010, Andrea Arcangeli wrote: > > > > Looks like SLUB also uses _mapcount for some fun purposes: > > > > > > struct page { > > > unsigned long flags; /* Atomic flags, some possibly > > > * updated asynchronously */ > > > atomic_t _count; /* Usage count, see below. */ > > > union { > > > atomic_t _mapcount; /* Count of ptes mapped in mms, > > > * to show when page is mapped > > > * & limit reverse map searches. > > > */ > > > struct { /* SLUB */ > > > u16 inuse; > > > u16 objects; > > > }; > > > }; > > > > > > I guess those don't *really* become a problem in practice until we get a > > > really large page size that can hold >=64k objects. But, at that point, > > > we're overflowing the types anyway (or really close to it). > > > > Maybe we should add a BUG_ON in slub in case anybody runs this on > > PAGE_SIZE == 2M (to avoid silent corruption). > > SLUB has been verified a long time ago to run fine with 2M pages. > > Just specify > > slub_min_order=9 > > on the kernel command line to get a system booted up with 2M slab pages. sure no doubt if order 9 == 2M it's no problem, what I meant is: #define PAGE_SIZE (4096*512) 2M >>> 64k so with order 0 == 2m I thought it might overflow, dunno! As far as PG_buddy removal is concerned, if I use -2 I don't think there can be any problem as it'd be next to overflow anyway like Dave said. -- 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