[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080102204435.GB15460@infradead.org>
Date: Wed, 2 Jan 2008 20:44:35 +0000
From: Christoph Hellwig <hch@...radead.org>
To: schwidefsky@...ibm.com
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.
On Mon, Nov 12, 2007 at 03:30:11PM +0100, schwidefsky@...ibm.com wrote:
> From: Martin Schwidefsky <schwidefsky@...ibm.com>
> Solution: The only solution I found to this dilemma is a new typedef:
> a pgtable_t. For s390 pgtable_t will be a (pte *) - to be introduced
> with a later patch. For everybody else it will be a (struct page *).
> The additional problem with the initialization of the ptl lock and the
> NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor
> and a destructor pgtable_page_dtor. The page table allocation and free
> functions need to call these two whenever a page table page is allocated
> or freed. pmd_populate will get a pgtable_t instead of a struct page
> pointer. To get the pgtable_t back from a pmd entry that has been
> installed with pmd_populate a new function pmd_pgtable is added. It
> replaces the pmd_page call in free_pte_range and apply_to_pte_range.
Can we please just nuke CONFIG_HIGHPTE? There's only been a small
amount of 32bit machines with so much memory that they'd need it
and they can happily stay on the currently supported enterprise
distro releases instead of dragging this cruft around forever.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists