![]() | |||||||||||||
Messages in this thread |
[ 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/ | ||||||||||||
| Last update: 2005-03-22 12:56 [W:0.327 / U:0.300 seconds] ©2003-2008 Jasper Spaans | |||||||||||||