SCHED_ULE should not be the default
attilio at freebsd.org
Thu Dec 15 16:26:06 UTC 2011
2011/12/14 Mike Tancsa <mike at sentex.net>:
> On 12/13/2011 7:01 PM, mdf at freebsd.org wrote:
>> Has anyone experiencing problems tried to set sysctl kern.sched.steal_thresh=1 ?
>> I don't remember what our specific problem at $WORK was, perhaps it
>> was just interrupt threads not getting serviced fast enough, but we've
>> hard-coded this to 1 and removed the code that sets it in
>> sched_initticks(). The same effect should be had by setting the
>> sysctl after a box is up.
> FWIW, this does impact the performance of pbzip2 on an i7. Using a 1.1G file
> pbzip2 -v -c big > /dev/null
> with burnP6 running in the background,
> sysctl kern.sched.steal_thresh=1
> sysctl kern.sched.steal_thresh=3
> N Min Max Median Avg Stddev
> x 10 38.005022 38.42238 38.194648 38.165052 0.15546188
> + 9 38.695417 40.595544 39.392127 39.435384 0.59814114
> Difference at 95.0% confidence
> 1.27033 +/- 0.412636
> 3.32852% +/- 1.08119%
> (Student's t, pooled s = 0.425627)
> a value of 1 is *slightly* faster.
was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE?
Also, the results here should be in the 3% interval for the avg case,
which is not yet at the 'alarm level' but could still be an
I still suspect I/O plays a big role here, however, thus it could be
detemined by other factors.
Could you retry the bench checking CPU usage and possible thread
migration around for both cases?
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-stable