> Thank you, that was very useful. I may have something to test very soon.
Sounds great Jeff, just say the word when you need someone to do the testing. I'll be glad to help! > What would be interesting to know is if the sum of the temperatures is any > different. 4BSD gets a much more random distribution of load because a > thread is run on whatever cpu context switches next. ULE will have > specific load patterns since it scans lists of cpus in a fixed order to > assign load. That seems to correlate with what I'm seeing, since the core that is "spiking" is cpu0. I will write a little perl script to calculate the sum periodically and record that. You're right, the one core may be increasing 1-2 C periodically, but the other cores may remain lower. I can definitely get you some numbers here. So I went ahead and ran sysbench to see if changing the kern.sched.slice value affected that (which I hear is a much more accurate benchmark of real world MySQL performance than, say, supersmack). There is a slight hit with the lower slice value, though it's minimal. Although with 4 threads, the lower slice value actually increases performance slightly. Here are the results (with 4BSD as a baseline): 4bsd ule.13 ule.7 2263.6 2250.36 2265.67 2181.18 2310.02 2300.25 2137.87 2304.04 2269.54 2100.41 2252.04 2249.26 buildworld isn't cooperating for me, but once I iron that out, I'll post some results there as well :) Thanks once again for all your efforts Jeff. I (and I'm sure others) really appreciate your work. Regards, Josh _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
