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

From: Ingo Molnar
Date: Mon Oct 10 2005 - 09:04:47 EST

* Roman Zippel <zippel@xxxxxxxxxxxxxx> 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.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at