> Josh, thanks for your help so far. This has been very useful. You're welcome, glad to help! Thanks for the effort and the patch.
> Any testing you can run this through is appreciated. Anyone else lurking > in this thread who would like to is also welcome to report back findings. Here are a few benchmarks comparing ULE and the patched ULE. I experimented in changing the slice_min value from 2 to 4, in case that might be useful info for you. Hopefully that helps a bit, but if not it's just a few minutes of CPU time wasted :) Sysbench results: # threads slice=7 slice=13 slice_min=4 slice_min=2 4 2265.67 2250.36 2261.71 2297.08 8 2300.25 2310.02 2306.79 2313.61 12 2269.54 2304.04 2296.54 2279.73 16 2249.26 2252.04 2260.53 2245.76 It looks like with the default minimum (2), the performance for systat is better with 4 and 8 threads (on a 4 core system), but worse for 12 and 16 threads. Here are the results for ffmpeg (-threads 8): slice=7 slice=13 slice_min=4 slice_min=2 1:37.00 1:39.09 1:38.12 1:38.06 The patch definitely improves things there, though not quite as good as using a slice value of 7. But it does improve things. So it slightly improves things for ffmpeg and also slightly increases the performance of sysbench/MySQL (with 8 threads). I also ran through buildworld for both slice_min of 2 and 4, and here are the results, again with ULE as a base line: slice=7 slice=13 slice_min=4 slice_min=2 13:40.56 13:44.28 13:46.64 13:45.80 So buildworld performance is about the same as with the default ULE and default slice value. Thanks, Josh _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"
