From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e23smtp06.au.ibm.com", Issuer "Equifax" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id A3414B7067 for ; Tue, 15 Sep 2009 16:41:46 +1000 (EST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id n8F6fbmG009777 for ; Tue, 15 Sep 2009 16:41:37 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8F6diln1441984 for ; Tue, 15 Sep 2009 16:39:44 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n8F6fhL7025301 for ; Tue, 15 Sep 2009 16:41:43 +1000 Date: Tue, 15 Sep 2009 16:41:33 +1000 From: David Gibson To: linuxppc-dev@lists.ozlabs.org, Benjamin Herrenschmidt Subject: [0/5] Assorted hugepage cleanups (v2) Message-ID: <20090915064133.GA11621@yookeroo.seuss> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Currently, ordinary pages use one pagetable layout, and each different hugepage size uses a slightly different variant layout. A number of places which need to walk the pagetable must first check the slice map to see what the pagetable layout then handle the various different forms. New hardware, like Book3E is liable to introduce more possible variants. This patch series, therefore, is designed to simplify the matter by limiting knowledge of the pagetable layout to only the allocation path. With this patch, ordinary pages are handled as ever, with a fixed 4 (or 3) level tree. All other variants branch off from some layer of that with a specially marked PGD/PUD/PMD pointer which also contains enough information to interpret the directories below that point. This means that things walking the pagetables (without allocating) don't need to look up the slice map, they can just step down the tree in the usual way, branching off to the "non-standard layout" path for hugepages, which uses the embdded information to interpret the tree from that point on. This reduces the source size in a number of places, and means that newer variants on the pagetable layout to handle new hardware and new features will need to alter the existing code in less places. In addition we split out the hash / classic MMU specific code into a separate hugetlbpage-hash64.c file. This will make adding support for other MMUs (like 440 and/or Book3E) easier. I've used the libhugetlbfs testsuite to test these patches on a Power5+ machine, but they could certainly do with more testing. In particular, I don't have any suitable hardware to test 16G pages. V2: Made the tweaks that BenH suggested to patch 2 of the original series. Some corresponding tweaks in patch 3 to match. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson