All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <christoph@lameter.com>
Cc: Andrea Arcangeli <andrea@novell.com>, Andi Kleen <ak@suse.de>,
	haveblue@us.ibm.com, linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: 4level page tables for Linux
Date: Mon, 18 Oct 2004 19:21:22 +0200	[thread overview]
Message-ID: <20041018172122.GD1945@verdi.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0410180957500.9916@server.graphe.net>

On Mon, Oct 18, 2004 at 10:02:20AM -0700, Christoph Lameter wrote:
> On Wed, 13 Oct 2004, Andrea Arcangeli wrote:
> 
> > On Wed, Oct 13, 2004 at 09:35:58PM +0200, Andi Kleen wrote:
> > > page mapping level 4 (?) just guessing here.
> >
> > make sense.
> >
> > > PML4 is the name AMD and Intel use in their documentation. I don't see
> > > a particular reason to be different from them.
> >
> > just because we never say 'page mapping level 4', we think 'page table
> > level 4' or 'page directory level 4'.
> 
> Would it not be best to give up hardcoding these page mapping levels into
> the kernel? Linux should support N levels. pml4,pgd,pmd,pte needs to

It already does. Currently it supports 2-3 levels, with my patch
it supports 2-4 levels.

> disappear and be replaced by
> 
> pte_path[N]
> 
> We are duplicating code for pgd, pmd, pte and now pml again and again. The
> code could be much simpler if this would be generalized. Various

For most people it is already generalized (get_user_pages).
The only exception is the core VM and the low level architecture code.
The later will need to deal always with the details.


> architectures would support different levels without some strange
> feature like f.e. pmd's being "optimized away".

Nobody came up with a nice automatic iterator so far.

If you look at the different functions in mm/* who handle all level 
they all do slightly different things so it's not that easy to 
generalize. Also it is not that many, perhaps seven in mm/* plus 
another in the arch code.

> Certainly the way that pml4 is proposed to be done is less invasive but we
> are creating something more and more difficult to maintain.

I don't see us switching to more levels any time soon ...

Also I don't think it's that bad as you're claiming it is. It's a clear
abstraction which has served us well so far.

-Andi


  reply	other threads:[~2004-10-18 17:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-12 13:59 4level page tables for Linux Andi Kleen
2004-10-12 18:48 ` Dave Hansen
2004-10-12 19:03   ` Andi Kleen
2004-10-12 19:08     ` 4level page tables for Linux II Andi Kleen
2004-10-13 18:41   ` 4level page tables for Linux Andrea Arcangeli
2004-10-13 19:35     ` Andi Kleen
2004-10-13 20:04       ` Andrea Arcangeli
2004-10-18 17:02         ` Christoph Lameter
2004-10-18 17:21           ` Andi Kleen [this message]
2004-10-18 17:38           ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2004-10-13 23:22 Albert Cahalan
2004-10-13 23:51 ` Andrea Arcangeli
2004-10-14  1:15   ` Albert Cahalan
2004-10-14  9:25 linux
2004-10-14 11:15 ` Robin Holt
2004-10-17  2:57 ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041018172122.GD1945@verdi.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=andrea@novell.com \
    --cc=christoph@lameter.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.