* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > i pointed it out how to port a larger series ontop of a whitespace
> > cleanup patch:
> >
> > http://lkml.org/lkml/2008/1/18/281
> >
> > the "there's an easy technique" bit.
>
> But it will be even easier to just redo the cleanup stuff at the end.
> If I do what you describe here I'm sure I will make a mistake
> somewhere and I would rather not risk that.
FYI, i've done the proper splitup of your CPA patchset - see today's
x86.git#mm for the details. I've extracted all the c_p_a() fixes from
your series and eliminated the 'undo cleanups' patch as well.
It's a first shot so it might not yet be perfect - although so far it
looks good in testing on 4-5 testsystems here, on mixed 64-bit and
32-bit boxes. Doing it this way was a pretty straightforward process, it
took less than an hour - and the end result feels much better in terms
of maintainability.
I left the clflush feature bits out for now - fixes and cleanups go
first. We first need to see whether this is robust enough before making
other changes to c_p_a(). There's enough on the arch/x86 plate for
v2.6.25 already - we can try the clflush optimizations in v2.6.26.
(since there's no high-freq in-kernel user of the c_p_a() API at the
moment, there's no pressing need for this either.)
Anyway, could you check today's x86.git and see whether any of those
fixes have some implicit dependency on other changes i left out of this
splitup? That's the main high-level risk i can see for now. (besides the
large number of changes to this fragile API)
Also, CPA_DEBUG still produces warnings all around the place - as it did
with your series.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
