Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[Ingo Molnar <mingo@elte.hu>]

* Roman Zippel <zippel@linux-m68k.org> wrote:

> > > Do you have any numbers (besides maybe microbenchmarks) that show a 
> > > real advantage by using per cpu data? What kind of usage do you expect 
> > > here?
> > 
> > it has countless advantages, and these days we basically only design 
> > per-CPU data structures within the kernel, unless some limitation (such 
> > as API or hw property) forces us to do otherwise. So i turn around the 
> > question: what would be your reason for _not_ doing this clean per-CPU 
> > design for SMP systems?
> 
> Did I say I'm against it? No, I was just hoping someone put some more 
> thought into it than just "all the other kids are doing it". I was 
> just curious how well it really scales compared to the simple version, 
> e.g. what happens if most timer end up on a single cpu or what happens 
> if we want to start the timer on a different cpu. Is this so wrong 
> that you have to go into attack mode? :(

[ sorry, and i didnt go into 'attack mode'. I believe you'll distinctly 
  notice when i do that :-) ]

just think NUMA, and the generic advantages of PER_CPU become obvious.  
(via PER_CPU the different data structures indexed can properly end up 
on another domain's RAM, and can thus improve caching characteristics.)

	Ingo