linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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