![]() | ||||||||||
Messages in this thread |
Jamie Lokier wrote: >Nick Piggin wrote: > >>>Shared runqueues sound like a simplification to describe execution units >>>which have shared resourses and null cost of changing units. You can do >>>that by having a domain which behaved like that, but a shared runqueue >>>sounds better because it would eliminate the cost of even considering >>>moving a process from one sibling to another. >>> >>You are correct, however it would be a miniscule cost advantage, >>possibly outweighed by the shared lock, and overhead of more >>changing of CPUs (I'm sure there would be some cost). >> > >Regarding the overhead of the shared runqueue lock: > >Is the "lock" prefix actually required for locking between x86 >siblings which share the same L1 cache? > That lock is still taken by other CPUs as well for eg. wakeups, balancing, and so forth. I guess it could be a very specific optimisation for spinlocks in general if there was only one HT core. Don't know if it would be worthwhile though. - 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-03-22 12:59 [from the cache] ©2003-2008 | ||||||||||