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: Tue, 21 Dec 2004 09:36:31 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0412210925370.4112@ppc970.osdl.org> (raw)
In-Reply-To: <20041221093628.GA6231@wotan.suse.de>
On Tue, 21 Dec 2004, Andi Kleen wrote:
>
> Sorry, but I think that's a very bad approach. If the i386 users
> don't get warnings I will need to spend a lot of time just patching
> behind them. While x86-64 is getting more and more popular most
> hacking still happens on i386.
That's true, but it's not an issue for several reasons:
- we can easily update just _x86_ to be type-safe (ie add the fourth
level to x86 just to get type safety, even if it's folded). That
doesn't mean that we have to worry about 20 _other_ architectures, that
most developers can't even test.
Iow, the lack of type-safety is not something forced by the approach.
The lack of type safety is an _option_ to allow architectures to not
have to have a flag-day when everybody needs to switch.
In fact, the lack of type-safety would allow every single intermediate
patch to always compile, and work - on all architectures. Which isn't
true in the current series, and which is a really nice feature, because
it means that you really can build up the thing entirely, up to the
point where you "turn it on" one architecture at a time.
- even if we left x86 type-unsafe, the fact is, the things that walk the
page tables almost never get changed. I don't remember the last time we
really changed things around all that much. So even without x86, it
likely wouldn't be a problem.
> Also is the flag day really that bad?
I think that _avoiding_ a flag-day is always good. Also, more importantly,
it looks like this approach allows each patch to be smaller and more
self-contained, ie we never have the situation where "uhhuh, now it won't
compile on arch Xxxx for ten patches, until we turn things on". The
smaller the patches are, the more obvious any problems will be.
Think of it this way: for random architecture X, the four-level page table
patches really should make _no_ difference until they are enabled. So you
can do 90% of the work, and be pretty confident that things work. Most
importantly, if things _don't_ work before the thing has been enabled,
that's a big clue ;)
And then, the last (small) patch for architecture X actually ends up
enabling the work. Everybody will be happier with something like that,
since it makes merging _much_ easier. For example, I'll have zero problems
at all with merging the infrastructure the day after 2.6.10 is released,
since I'll know that it won't hurt any of the other architectures, and it
won't make trouble for anybody.
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-21 17:36 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
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 [this message]
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.0412210925370.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