From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
akpm@linux-foundation.org, Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH] fix/improve generic page table walker
Date: Mon, 16 Mar 2009 13:55:44 +0100 [thread overview]
Message-ID: <20090316135544.52719f04@skybase> (raw)
In-Reply-To: <20090316123654.GF30802@wotan.suse.de>
On Mon, 16 Mar 2009 13:36:54 +0100
Nick Piggin <npiggin@suse.de> wrote:
> > With the page table folding "3 levels removed from the bottom" doesn't
> > tell me much since there is no real representation in hardware AND in
> > memory for the missing page table levels. So the only valid meaning of
> > a pgd_t is that you have to use pud_offset, pmd_offset and pte_offset
> > to get to a pte. If I do the page table folding at runtime or at
> > compile time is a minor detail.
>
> I don't know if it would be helpful to you, but I solve a similar
> kind of problem in the lockless radix tree by encoding node height
> in the node itself. Maybe you could use some bits in the page table
> pointers or even in the struct pages for this.
That is what I already do: there are two bits in the region and segment
table entries that tell me at what level I am (well actually it is the
hardware definition that requires me to do that and I just make use of
it). The page table primitives (pxd_present, pxd_offset, etc) look at
these bits and then do the right thing.
What is killing me is the pgd++/pud++ operation. If there is only a 2
or 3 level page table the pointer increase may not happen. This is done
by a correct end address for the walk.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
akpm@linux-foundation.org, Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH] fix/improve generic page table walker
Date: Mon, 16 Mar 2009 13:55:44 +0100 [thread overview]
Message-ID: <20090316135544.52719f04@skybase> (raw)
In-Reply-To: <20090316123654.GF30802@wotan.suse.de>
On Mon, 16 Mar 2009 13:36:54 +0100
Nick Piggin <npiggin@suse.de> wrote:
> > With the page table folding "3 levels removed from the bottom" doesn't
> > tell me much since there is no real representation in hardware AND in
> > memory for the missing page table levels. So the only valid meaning of
> > a pgd_t is that you have to use pud_offset, pmd_offset and pte_offset
> > to get to a pte. If I do the page table folding at runtime or at
> > compile time is a minor detail.
>
> I don't know if it would be helpful to you, but I solve a similar
> kind of problem in the lockless radix tree by encoding node height
> in the node itself. Maybe you could use some bits in the page table
> pointers or even in the struct pages for this.
That is what I already do: there are two bits in the region and segment
table entries that tell me at what level I am (well actually it is the
hardware definition that requires me to do that and I just make use of
it). The page table primitives (pxd_present, pxd_offset, etc) look at
these bits and then do the right thing.
What is killing me is the pgd++/pud++ operation. If there is only a 2
or 3 level page table the pointer increase may not happen. This is done
by a correct end address for the walk.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-03-16 13:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 13:49 [PATCH] fix/improve generic page table walker Martin Schwidefsky
2009-03-11 13:49 ` Martin Schwidefsky
2009-03-11 17:24 ` Matt Mackall
2009-03-11 17:24 ` Matt Mackall
2009-03-12 8:33 ` Martin Schwidefsky
2009-03-12 8:33 ` Martin Schwidefsky
2009-03-12 10:19 ` Martin Schwidefsky
2009-03-12 10:19 ` Martin Schwidefsky
2009-03-12 11:24 ` Martin Schwidefsky
2009-03-12 11:24 ` Martin Schwidefsky
2009-03-12 14:10 ` Matt Mackall
2009-03-12 14:10 ` Matt Mackall
2009-03-12 14:42 ` Martin Schwidefsky
2009-03-12 14:42 ` Martin Schwidefsky
2009-03-12 15:58 ` Matt Mackall
2009-03-12 15:58 ` Matt Mackall
2009-03-16 12:27 ` Martin Schwidefsky
2009-03-16 12:27 ` Martin Schwidefsky
2009-03-16 12:36 ` Nick Piggin
2009-03-16 12:36 ` Nick Piggin
2009-03-16 12:55 ` Martin Schwidefsky [this message]
2009-03-16 12:55 ` Martin Schwidefsky
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=20090316135544.52719f04@skybase \
--to=schwidefsky@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=gerald.schaefer@de.ibm.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=npiggin@suse.de \
/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.