![]() | |||||||||||||
Messages in this thread |
* 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 - 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-10 14:06 [from the cache] ©2003-2008 | |||||||||||||