From: Linus Torvalds <torvalds@transmeta.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
Hubertus Franke <frankeh@watson.ibm.com>,
wli@holomorpy.comgh@us.ibm.com, swj@cse.unsw.edu.au,
linux-mm mailing list <linux-mm@kvack.org>
Subject: Re: large page patch (fwd) (fwd)
Date: Fri, 2 Aug 2002 18:26:29 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.44.0208021757490.2210-100000@home.transmeta.com> (raw)
In-Reply-To: <3D4B2535.2B1F5BF8@zip.com.au>
On Fri, 2 Aug 2002, Andrew Morton wrote:
>
> Remind me again what's wrong with wrapping the Intel syscalls
> inside malloc() and then maybe grafting a little hook into the shm code?
Indeed.
However, don't think "Intel syscalls", think instead "bring out the
architecture-defined mapping features". In particular, the main objection
I had to Ingo's patch (which, by the sound of it is fairly similar to the
IBM patches which I haven't seen) was that it was much too Intel-centric.
I admit to being x86-centric when it comes to implementation (simply due
to the fact that they are cheap and everywhere), but I try very hard to
avoid making _design_ revolve around x86. In particular, while I'm not a
big fan of the PPC hash tables (understatement of the year), I _do_ like
the BAT mapping that PPC has.
(Alternatively, if you aren't familiar with BAT registers, think
software-filled extra TLB entries that are outside the normal fill policy
and have large sizes. For some architectures it makes sense to do this at
sw TLB fill time, for others that isn't very practical because the page
table lookup is fixed in various ways.)
This is sometimes also referred to as "superpages".
And I think people will find the "separate path" approach more palatable
if you think of it as an interface to BAT registers (with the "normal" VM
path being the interface to the regular page tables). And keeping very
much in mind that on some CPU's these two things really _are_ totally
separate (PPC being the best example).
The fact that on x86, which doesn't have a BAT array, we use the
PMD-spanning "large pages" instead, should be seen as the anomaly, not as
the design case.
This also hopefully explains why I consider anything that touches or cares
about page tables in generic VM code wrt the largepage support to be
fundamentally broken. If the largepage patch messes around with page
tables, it cannot be generic.
Linus
--
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/
next prev parent reply other threads:[~2002-08-03 1:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0208021252090.2466-100000@penguin.transmeta.com>
2002-08-02 23:54 ` Martin J. Bligh
2002-08-03 0:35 ` Andrew Morton
2002-08-03 1:26 ` Linus Torvalds [this message]
2002-08-03 4:26 ` Gerrit Huizenga
2002-08-03 4:39 ` Linus Torvalds
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=Pine.LNX.4.44.0208021757490.2210-100000@home.transmeta.com \
--to=torvalds@transmeta.com \
--cc=Martin.Bligh@us.ibm.com \
--cc=akpm@zip.com.au \
--cc=frankeh@watson.ibm.com \
--cc=wli@holomorpy.comgh \
/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