LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: benh@kernel.crashing.org, schwidefsky@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.
Date: Sun, 3 Feb 2008 07:46:45 +0100	[thread overview]
Message-ID: <20080203064645.GA27929@elte.hu> (raw)
In-Reply-To: <20080202215315.3ac6907d.akpm@linux-foundation.org>


* Andrew Morton <akpm@linux-foundation.org> wrote:

> > It's a sane patch and a helps going further, and a total pain to 
> > re-do later on. Besides, I may have some use for it on powerpc at 
> > some point too...
> 
> OK, I'll try to reestablish it.
> 
> Look: I can't fix *everyone's* stuff.  This was a consequence of 
> ongoing unbounded churn in the x86 tree. [...]

i've reviewed this patchset and the right model appears to me to do this 
change upstream right now, atomically. It is supposed to be a pure 
functional NOP, and any deviation from that is easy to spot.

  Acked-by: Ingo Molnar <mingo@elte.hu>

I dont think it's particular wise to maintain a change like this across 
all the arch churn, for months. This patch is a pure cleanup, it could 
have been merged two months ago. The author should get agreement that 
it's fine to do it, and if the timing happens to be unfortunate for 
immediate merging (we are within say 1 month window before stable 
release) then delay it and redo the cleanup right when it's about to be 
merged.

The worst thing to do is to prolong this for months - it is only 
unnecessary work for no particular good reason. It complicates -mm 
merging, keeps an API fork around for no good reason, etc., etc.

there's tons of past examples of much larger transformations than this 
done right: for example the recent irq_regs changes. (and that one wasnt 
even a pure NOP like this change.)

In general, we can pick up the x86 bits of any tree-wide change into 
x86.git no problem, and then maintain it against all the nuances of 
x86.git churn. (That requires them to be shaped in a way so that they 
can be applied to one architecture at a time - which is obviously a good 
thing anyway - but not always possible, such as in this case where a 
common API is extended.)

If anyone is feeling _any_ serious effects of x86.git churn then please 
talk to us maintainers and we can work out some technical solution. The 
only thing we cannot do is to stop 100 active contributors and the flow 
of 1000 patches until someone finds the time to get tree-wide changes 
upstream.

Roland was able to shape his utrace-enabler regset patches upstream this 
way, and it is two or three orders of magnitude more complex of a code 
transformation than the one we are talking about here.

	Ingo

  reply	other threads:[~2008-02-03  6:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-12 14:30 [patch 0/3] page table changes schwidefsky
2007-11-12 14:30 ` [patch 1/3] add mm argument to pte/pmd/pud/pgd_free schwidefsky
2007-11-12 14:30 ` [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables schwidefsky
2008-01-02 20:44   ` Christoph Hellwig
2008-01-02 21:24     ` Geert Uytterhoeven
2008-01-02 21:28       ` Benjamin Herrenschmidt
2008-01-03 13:12     ` Andi Kleen
2008-01-03 14:01       ` Boaz Harrosh
2008-02-01 23:15   ` Andrew Morton
2008-02-03  5:37     ` Benjamin Herrenschmidt
2008-02-03  5:53       ` Andrew Morton
2008-02-03  6:46         ` Ingo Molnar [this message]
2008-02-04 10:36         ` Martin Schwidefsky
2008-02-04 10:51           ` Andrew Morton
2008-02-04 11:02             ` Russell King
2008-02-04 11:14               ` Andrew Morton
2008-02-05 14:39             ` Martin Schwidefsky
2008-02-05 18:46               ` Andrew Morton
2008-02-06  9:06                 ` Martin Schwidefsky
2008-02-06  9:09                   ` Andrew Morton
2008-02-06  9:15                     ` Ingo Molnar
2008-02-06 15:50                     ` Martin Schwidefsky
2007-11-12 14:30 ` [patch 3/3] arch_rebalance_pgtables call schwidefsky
2007-11-13 12:33   ` Nick Piggin
2007-11-14  9:26     ` Martin Schwidefsky
2007-11-14 10:06       ` Benjamin Herrenschmidt
2007-11-14 11:49         ` Martin Schwidefsky
2007-11-14 22:07           ` Benjamin Herrenschmidt
2007-11-15 17:13             ` Martin Schwidefsky

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=20080203064645.GA27929@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --subject='Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.' \
    /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

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).