[ Friday, January 21, 2000 ] Chuck Lever wrote:
> what might be nice is having the kernel configuration process select the
> proper constant values based on the CPU hardware type you've selected, and
> whether SMP is enabled.
My initial feeling agreed with this, but after Andrea mentioned
self-tuning and a few cases were brought up, I realize that it's
dependent upon the process mix of the workload. Good loop-blocking code
will be very sensitive but programs just dealing with external input
(streaming files, network input, etc) shouldn't be nearly as sensitive
as the D$ misses are going to be there on any processor. How harmful
the I$ misses are will depend on the code characteristics/working set.
Streaming apps which deal with data once and toss it vs. block-processing
(rc5, setiathome, jpeg-ish kinds of things) programs should be handled
differently. In much the same manner as your madvise() additions helped
bring that reality to the kernel for mmap() behavior, the scheduler
should more sensitive to these differences if possible.
Now since self-tuning can be tricky (if not just unrealistic) selecting
a good value at compile time could be a good idea, but if, say, SMP P6
is selected that still doesn't help differentiate between 2-way PPro's
and 128K celeron's from 8-way 2MB Xeon's, and esp. with the Profusion
around and the competition of more and larger caches per bus, I'm not
sure this range is very tight.
A "least evil" number could be selected, though, but I get the feeling
that we'd be better off just making the static int default to whatever
that number turns out to be. Testing across platforms, though, could
prove me wrong and the range could be tight, but allowing the /proc
entries to be settable gives the ultimate flexibility.
Just to make sure I'm not missing something... if SMP's not enabled then
processor change doesn't even make sense, so allowing it to be tunable
or picking a different value for it won't matter. Now the TLB flush
penalty could definitely vary per-CPU, and picking a good default value
for this based on CPU hardware type at config time does make sense.
James
-- Miscellaneous Engineer --- IBM Netfinity Performance Development- 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 : Sun Jan 23 2000 - 21:00:25 EST