This is really about lat_ctx performance on SMP...
lat_ctx performance should not be optimized on SMP. A good SMP scheduler
will have fairly poor lat_ctx performance. We played around with the
IRIX scheduler at SGI trying to improve lat_ctx performance and I came
to the conclusion that it's not a good thing. Here's why:
lat_ctx is a ring of processes connected with a pipe. There is only one
running process at any time, all the processes pass a single token by
doing
for (;;) {
read(in, &c, 1);
do_some_work();
write(out, &c, 1);
}
so as soon as they wake up to read the byte, they get rid of it and
go back to sleep waiting for it to come back.
The do_some_work() function is affected by -s XXX - if XXX is non zero,
the process forces XXX Kbytes of data into the cache.
For the 0 sized case, the absolute best performance is if all the
processes are on the same CPU and cache. Since only one is running at
any time, it's faster to switch locally. At sgi, a "runon 0 lat_ctx 2
2 2 2" got substantially better performance (runon binds all to that cpu).
As the size gets bigger, you want them spread out.
Anyway, I'm tired so this explanation probably sucks, but the bottom
line is that if you optimize your scheduler for lat_ctx on an SMP,
you probably made it slower for real workloads. If Linux has a way to
bind processes to particular CPUs, you should play with that. Look
at lat_ctx.c and search for "PIN" and you'll see irix specific code
to pin the processes to different cpus, you get dramatically different
results when you do this.
If this has done nothing but confuse you, send mail, I'll try again.
Back to BitKeeper...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:18 EST