SCHED_ULE should not be the default
Attilio Rao
attilio at freebsd.org
Thu Dec 15 16:49:31 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
> vs
> 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.
Hi Mike,
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
indication.
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?
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-performance
mailing list