* Andi Kleen <ak@suse.de> wrote:

quoted text
> > 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/