From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755835AbXD0Nmi (ORCPT ); Fri, 27 Apr 2007 09:42:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755837AbXD0Nmi (ORCPT ); Fri, 27 Apr 2007 09:42:38 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:37590 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755835AbXD0Nmh (ORCPT ); Fri, 27 Apr 2007 09:42:37 -0400 Date: Fri, 27 Apr 2007 14:42:01 +0100 From: Christoph Hellwig To: Paul Mackerras Cc: Nick Piggin , Andrew Morton , Christoph Lameter , David Chinner , linux-kernel@vger.kernel.org, Mel Gorman , William Lee Irwin III , Jens Axboe , Badari Pulavarty , Maxim Levitsky Subject: Re: [00/17] Large Blocksize Support V3 Message-ID: <20070427134201.GC4152@infradead.org> Mail-Followup-To: Christoph Hellwig , Paul Mackerras , Nick Piggin , Andrew Morton , Christoph Lameter , David Chinner , linux-kernel@vger.kernel.org, Mel Gorman , William Lee Irwin III , Jens Axboe , Badari Pulavarty , Maxim Levitsky References: <20070426190438.3a856220.akpm@linux-foundation.org> <20070427022731.GF65285596@melbourne.sgi.com> <20070426195357.597ffd7e.akpm@linux-foundation.org> <20070427042046.GI65285596@melbourne.sgi.com> <20070426221528.655d79cb.akpm@linux-foundation.org> <20070426235542.bad7035a.akpm@linux-foundation.org> <17969.55533.59287.509889@cargo.ozlabs.ibm.com> <4631E173.7000204@yahoo.com.au> <17969.59676.356383.189020@cargo.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17969.59676.356383.189020@cargo.ozlabs.ibm.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2007 at 10:14:20PM +1000, Paul Mackerras wrote: > It's not as simple on 64-bit powerpc with the hash table of course, > because the page size is chosen at the segment (256MB) level, > restricting where we can put 64k and 16M pages to some degree. I think Christoph's variable order pagecache should be perfectly fine on ppc64. We're selecting the pagesize on a per-file basis, and the page size selection would choce which segement this mmap gets into. Ben's get_unmapped_area changes are very helpfull for that.