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

[Ingo Molnar]

* Roman Zippel <zippel@xxxxxxxxxxxxxx> wrote:

> > +/* The time bases */
> > +#define MAX_KTIMER_BASES	2
> > +static DEFINE_PER_CPU(struct ktimer_base, ktimer_bases[MAX_KTIMER_BASES]) =
> 
> 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?

> The other thing is that this assumes, that all time sources are 
> programmable per cpu, otherwise it will be more complicated for a time 
> source to run the timers for every cpu, I don't know how safe that 
> assumption is. Changing the array of structures into an array of 
> pointers to the structures would allow to switch between percpu bases 
> and a single base.

yeah, and that's an assumption that simplifies things on SMP 
significantly. PIT on SMP systems for HRT is so gross that it's not 
funny. If anyone wants to revive that notion, please do a separate patch 
and make the case convincing enough ...

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/