Re: [GIT PULL] percpu for 2.6.31

[Ingo Molnar <mingo@elte.hu>]

* Tejun Heo <tj@kernel.org> wrote:

> Hello, again.
> 
> Tejun Heo wrote:
> > Oops, my apologies.  I had them as floating series and apparently used
> > different base commit when applying them.  I did grep run and full yes
> > build on the original quilt tree but didn't after quiltimport.  Sorry.
> 
> I digged through git changelogs to find out where it went wrong.  
> I did use the same base commit when quiltimporting but when I 
> updated the patches on top of mainline two days ago, I forgot to 
> quilt add the file and the mce change got committed to the base 
> tree instead of quilt patch.  After pulling the latest master into 
> the quilt branch yesterday, I updated the series for newcomers and 
> everything worked fine (as the base tree change got merged by 
> git).  quiltimporting of course lost the base tree change and 
> thinking the output gotta be identical I didn't test the final git 
> tree.
> 
> Anyways, I'm dropping the for-linus branch from percpu tree, 
> fixing it up, adding patchsets scheduled for .32 release and will 
> try to get it merged into #linux-next.

Please create a -git based bit for the x86 side (as i asked you 
previously) - we can certainly get that upstream sooner after the 
necessary amount of testing.

Condolences for trying to improve a dozen SMP architectures at once, 
you've ended up with:

 - being forced to rebase all the time. (This will happen in the
   cycle to come too: just watch as the conflicts in linux-next
   mount up with the architecture trees. Your tree will become
   crappy quickly due to the combined noise.)

 - the 10x patch logistics end up killing your overall quality, let
   crap creep in and cause breakage even on x86.

You wasted 3 months of your life on that. Now you've learned not to 
do that ever again - i've been there, done that, got the T-shirt.

Just stick your new stuff behind an ARCH_HAS flag, add it to the 
architecture(s) you care about and forget about the rest - let the 
remaining arch maintainers pick things up in their own pace. You'll 
get 90% of the benefits to Linux with just 30% of the work.

( Many wont btw: we still dont have lockdep support in all
  architectures - 3 years and counting. It's a highly useful purely
  sw feature with zero hardware dependencies. Fortunately it's
  well-modularized and the functionality is non-essential. Percpu
  allocation is not so lucky as it's essential functionality. )

	Ingo