[lkml]   [2006]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RFC] smt nice introduces significant lock contention
On Friday 02 June 2006 20:30, Con Kolivas wrote:
> On Friday 02 June 2006 18:56, Nick Piggin wrote:
> > And why do we lock all siblings in the other case, for that matter? (not
> > that it makes much difference except on niagara today).
> If we spinlock (and don't trylock as you're proposing) we'd have to do a
> double rq lock for each sibling. I guess half the time double_rq_lock will
> only be locking one runqueue... with 32 runqueues we either try to lock all
> 32 or lock 1.5 runqueues 32 times... ugh both are ugly.

Thinking some more on this it is also clear that the concept of per_cpu_gain
for smt is basically wrong once we get beyond straight forward 2 thread
hyperthreading. If we have more than 2 thread units per physical core, the
per cpu gain per logical core will decrease the more threads are running on
it. While it's always been obvious the gain per logical core is entirely
dependant on the type of workload and wont be a simple 25% increase in cpu
power, it is clear that even if we assume an "overall" increase in cpu for
each logical core added, there will be some non linear function relating
power increase to thread units used. :-|

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

 \ /
  Last update: 2006-06-02 15:19    [W:0.101 / U:1.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site