[lkml]   [2001]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CPU affinity & IPI latency
    On Thu, Jul 12, 2001 at 05:36:41PM -0700, Larry McVoy wrote:
    > Be careful tuning for LMbench (says the author :-)
    > Especially this benchmark. It's certainly possible to get dramatically better
    > SMP numbers by pinning all the lat_ctx processes to a single CPU, because
    > the benchmark is single threaded. In other words, if we have 5 processes,
    > call them A, B, C, D, and E, then the benchmark is passing a token from
    > A to B to C to D to E and around again.
    > If the amount of data/instructions needed by all 5 processes fits in the
    > cache and you pin all the processes to the same CPU you'll get much
    > better performance than simply letting them float.
    > But making the system do that naively is a bad idea.

    I agree, and can't imagine the system ever attempting to take this
    into account and leave these 5 tasks on the same CPU.

    At the other extreme is my observation that 2 tasks on an 8 CPU
    system are 'round robined' among all 8 CPUs. I think having the
    2 tasks stay on 2 of the 8 CPUs would be an improvement with respect
    to CPU affinity. Actually, the scheduler does 'try' to do this.

    It is clear that the behavior of lat_ctx bypasses almost all of
    the scheduler's attempts at CPU affinity. The real question is,
    "How often in running 'real workloads' are the schduler's attempts
    at CPU affinity bypassed?".

    Mike Kravetz
    IBM Linux Technology Center
    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: 2005-03-22 13:17    [W:0.022 / U:6.464 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site