Re: SCHED_ULE should not be the default

Attilio Rao <[email protected]>
Newsgroups gmane.os.freebsd.stable,gmane.os.freebsd.current,gmane.os.freebsd.performance
Message-ID <CAJ-FndBP1C5W-LAB4QF-ro+uaEaTx7ZzAAS3nXFY_82WXt53YQ@mail.gmail.com>
2011/12/14 Mike Tancsa <[email protected]>:
> On 12/13/2011 7:01 PM, [email protected] 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.