From: Linus Torvalds <torvalds@osdl.org>
To: Andi Kleen <ak@suse.de>
Cc: Hugh Dickins <hugh@veritas.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Linux Memory Management <linux-mm@kvack.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC][PATCH 0/10] alternate 4-level page tables patches
Date: Mon, 20 Dec 2004 10:40:07 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0412201016260.4112@ppc970.osdl.org> (raw)
In-Reply-To: <20041220180435.GG4316@wotan.suse.de>
On Mon, 20 Dec 2004, Andi Kleen wrote:
>
> But I'm not strongly opposed to it. If everybody else thinks "pud_t"
> is the greatest thing since sliced bread and much a much better name
> than "pml4_t" then I guess we could eat the delay and disruption
> that another round of these disruptive patches takes.
To me, it's not the name, but the _placement_.
"pml4_t" is at the _top_, and replaces "pgd_t" in that position. While
"pud_t" is in the _middle_, and extends upon the existing practice of
folding the mid directory.
I had a reason why I put "pmd_t" in between the old pgd_t and pte_t when I
expanded from two to three levels: it ends up adding the levels at the
point where they are conceptually the least intrusive.
By "conceptually least intrusive", think about this: one of the most core
header files in the kernel, <linux/sched.h> mentions "pgd_t", but it does
_not_ mention "pmd_t". Why?
Basically, by doing the new folded table in the middle, it _only_ affects
code that actually walks the page tables. Basically, what I wanted in the
original 2->3 leval expansion was that people who don't use the new level
should be able to conceptually totally ignore it. I think that is even
more true in the 3->4 level expansion.
I haven't done any side-by-side comparisons on your original patches, and
on Nick's version of your patches, but I'm pretty certain that Nick's
patches are more "directed", with less noise. Not because of any name
issues, but because I think the right place to do the folding is in the
middle.
Quite frankly, I don't love Nick's patches either. I'd prefer to see the
infrastructure happen first - have the patch sequence first make _every_
single architecture use the "generic pud_t folding", and basically be in
the position where the first <n> patches just do the syntactic part that
makes it possible for then patches <n+1>, <n+2> to actually convert
individual architectures that want it.
But Nick's patches seem to come fairly close to that.
So no, naming isn't the big difference. The conceptual difference is
bigger. It's just that once you conceptually do it in the middle, a
numbered name like "pml4_t" just doesn't make any sense (I don't think it
makes much sense at the top either, since there is no 1..2..3 to match it,
but that's a separate issue ;)
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-12-20 18:40 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-18 6:55 Nick Piggin
2004-12-18 6:55 ` [PATCH 1/10] " Nick Piggin
2004-12-18 6:56 ` [PATCH 2/10] " Nick Piggin
2004-12-18 6:56 ` [PATCH 3/10] " Nick Piggin
2004-12-18 6:57 ` [PATCH 4/10] " Nick Piggin
2004-12-18 6:58 ` [PATCH 5/10] " Nick Piggin
2004-12-18 6:58 ` [PATCH 6/10] " Nick Piggin
2004-12-18 6:59 ` [PATCH 7/10] " Nick Piggin
2004-12-18 7:00 ` [PATCH 8/10] " Nick Piggin
2004-12-18 7:00 ` [PATCH 9/10] " Nick Piggin
2004-12-18 7:01 ` [PATCH 10/10] " Nick Piggin
2004-12-18 7:31 ` Andi Kleen
2004-12-18 7:46 ` Nick Piggin
2004-12-18 8:08 ` Andrew Morton
2004-12-18 9:48 ` Andi Kleen
2004-12-18 19:06 ` Linus Torvalds
2004-12-20 17:43 ` Andi Kleen
2004-12-20 17:47 ` Randy.Dunlap
2004-12-20 18:08 ` Linus Torvalds
2004-12-20 18:15 ` Linus Torvalds
2004-12-20 18:19 ` Andi Kleen
2004-12-20 18:47 ` Linus Torvalds
2004-12-20 18:52 ` Linus Torvalds
2004-12-20 18:59 ` Andi Kleen
2004-12-20 18:57 ` Randy.Dunlap
2004-12-18 9:05 ` [PATCH 4/10] " Nick Piggin
2004-12-18 9:50 ` Andi Kleen
2004-12-18 10:06 ` Nick Piggin
2004-12-18 10:11 ` Andi Kleen
2004-12-18 10:22 ` Nick Piggin
2004-12-18 10:29 ` Nick Piggin
2004-12-18 11:06 ` William Lee Irwin III
2004-12-18 11:17 ` Nick Piggin
2004-12-18 11:32 ` William Lee Irwin III
2004-12-18 11:55 ` Nick Piggin
2004-12-18 12:46 ` William Lee Irwin III
2004-12-18 12:48 ` William Lee Irwin III
2004-12-19 0:05 ` Nick Piggin
2004-12-19 0:20 ` William Lee Irwin III
2004-12-19 0:38 ` Nick Piggin
2004-12-19 1:01 ` William Lee Irwin III
2004-12-19 1:31 ` Linus Torvalds
2004-12-19 2:08 ` William Lee Irwin III
2004-12-19 2:26 ` Nick Piggin
2004-12-19 5:23 ` Linus Torvalds
2004-12-19 6:02 ` William Lee Irwin III
2004-12-19 18:17 ` Linus Torvalds
2004-12-20 1:00 ` William Lee Irwin III
2004-12-18 10:45 ` William Lee Irwin III
2004-12-18 10:58 ` Nick Piggin
2004-12-19 0:07 ` [RFC][PATCH 0/10] " Hugh Dickins
2004-12-19 0:33 ` Nick Piggin
2004-12-20 18:04 ` Andi Kleen
2004-12-20 18:40 ` Linus Torvalds [this message]
2004-12-20 18:53 ` Andi Kleen
2004-12-21 0:04 ` Linus Torvalds
2004-12-21 0:22 ` Andi Kleen
2004-12-21 0:43 ` Linus Torvalds
2004-12-21 0:47 ` Nick Piggin
2004-12-21 2:55 ` Hugh Dickins
2004-12-21 3:21 ` Nick Piggin
2004-12-21 3:47 ` Linus Torvalds
2004-12-21 3:56 ` Linus Torvalds
2004-12-21 4:04 ` Nick Piggin
2004-12-21 4:08 ` Nick Piggin
2004-12-21 9:36 ` Andi Kleen
2004-12-21 10:13 ` Hugh Dickins
2004-12-21 10:59 ` Nick Piggin
2004-12-21 17:36 ` Linus Torvalds
2004-12-21 20:19 ` Andi Kleen
2004-12-21 23:49 ` Nick Piggin
2004-12-22 10:38 ` Andi Kleen
2004-12-22 11:19 ` Nick Piggin
2004-12-22 11:23 ` Nick Piggin
2004-12-22 18:07 ` Andi Kleen
2004-12-30 21:24 ` Nick Piggin
2004-12-21 10:52 ` 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=Pine.LNX.4.58.0412201016260.4112@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/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