![]() | ||||||||||
Messages in this thread |
* Roman Zippel <zippel@linux-m68k.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-10-01 09:24 [W:1.483 / U:0.070 seconds] ©2003-2008 Jasper Spaans | ||||||||||