[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.021 / U:0.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site