[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.586 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site