From: Nick Piggin <npiggin@suse.de>
To: Martin Schwidefsky <martin.schwidefsky@de.ibm.com>,
carsteno@linux.vnet.ibm.com,
Heiko Carstens <h.carstens@de.ibm.com>,
Jared Hulbert <jaredeh@gmail.com>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-arch@vger.kernel.org
Subject: Re: [rfc][patch] mm: use a pte bit to flag normal pages
Date: Mon, 7 Jan 2008 12:14:45 +0100 [thread overview]
Message-ID: <20080107111445.GB19872@wotan.suse.de> (raw)
In-Reply-To: <20080107103028.GA9325@flint.arm.linux.org.uk>
On Mon, Jan 07, 2008 at 10:30:29AM +0000, Russell King wrote:
> On Mon, Jan 07, 2008 at 05:43:55AM +0100, Nick Piggin wrote:
> > We initially wanted to do the whole vm_normal_page thing this way, with
> > another pte bit, but we thought there were one or two archs with no spare
> > bits. BTW. I also need this bit in order to implement my lockless
> > get_user_pages, so I do hope to get it in. I'd like to know what
> > architectures cannot spare a software bit in their pte_present ptes...
>
> ARM is going to have to use the three remaining bits we have in the PTE
> to store the memory type to resolve bugs on later platforms. Once they're
> used, ARM will no longer have any room for any further PTE expansion.
OK, it is good to have a negative confirmed. So I think we should definitely
get the non-pte-bit based mapping schemes working and tested on all platforms
before using a pte bit mapping...
FWIW, it might be possible for platforms to implement lockless get_user_pages
in other ways too. But that's getting ahead of myself.
Thanks.
next prev parent reply other threads:[~2008-01-07 11:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071221104701.GE28484@wotan.suse.de>
[not found] ` <OFEC52C590.33A28896-ONC12573B8.0069F07E-C12573B8.006B1A41@de.ibm.com>
2008-01-07 4:43 ` [rfc][patch] mm: use a pte bit to flag normal pages Nick Piggin
2008-01-07 10:30 ` Russell King
2008-01-07 11:14 ` Nick Piggin [this message]
2008-01-07 18:49 ` Jared Hulbert
2008-01-07 19:45 ` Russell King
2008-01-07 22:52 ` Jared Hulbert
2008-01-08 2:37 ` Andi Kleen
2008-01-08 2:49 ` Nick Piggin
2008-01-08 3:31 ` Andi Kleen
2008-01-08 3:52 ` Nick Piggin
2008-01-08 10:11 ` Catalin Marinas
2008-01-08 10:52 ` Russell King
2008-01-08 13:54 ` Catalin Marinas
2008-01-08 14:08 ` Russell King
2008-01-10 13:33 ` Carsten Otte
2008-01-10 23:18 ` Nick Piggin
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=20080107111445.GB19872@wotan.suse.de \
--to=npiggin@suse.de \
--cc=carsteno@linux.vnet.ibm.com \
--cc=h.carstens@de.ibm.com \
--cc=jaredeh@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.schwidefsky@de.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).