Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.

Ingo Molnar
2008-02-03T06:47:26Z

* 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