On Wed, 2 Nov 2016 10:23:24 -0400 George Mitchell <george+freebsd at
m5p.com>
wrote:>On 11/01/16 23:45, Kevin Oberman wrote:
>> On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening <jason.harmening at
gmail.com>
>> wrote:
>>
>>> Sorry, that should be ~*30ms* to get 30fps, though the variance is
still
>>> up to 500ms for me either way.
>>>
>>> On 11/01/16 14:29, Jason Harmening wrote:
>>>> repro code is at http://pastebin.com/B68N4AFY if anyone's
interested.
>>>>
>>>> On 11/01/16 13:58, Jason Harmening wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I recently upgraded my main amd64 server from 10.3-stable
(r302011) to
>>>>> 11.0-stable (r308099). It went smoothly except for one big
issue:
>>>>> certain applications (but not the system as a whole)
respond very
>>>>> sluggishly, and video playback of any kind is extremely
choppy.
>>>>>
>>>>> [...]
>> I eliminated the annoyance by change scheduler from ULE to 4BSD. That
was
>> it, but I have not seen the issue since. I'd be very interested in
whether
>> the scheduler is somehow impacting timing functions or it's s
different
>> issue. I've felt that there was something off in ULE for some time,
but it
>> was not until these annoying hiccups convinced me to try going back to
>> 4BSD.
>>
>> Tip o' the hat to Doug B. for his suggestions that ULE may have
issues that
>> impacted interactivity.
>> [...]
>
>Not to beat a dead horse, but I've been a non-fan of SCHED_ULE since
>it was first introduced, and I don't like it even today. I run the
>distributed.net client on my machines, but even without that, ULE
>screws interactive behavior. With distributed.net running and ULE,
>a make buildworld/make buildkernel takes 10 2/3 hours on 10.3-RELEASE
>on a 6-CPU machine versus 2 1/2 hours on the same machine with 4BSD
>and distributed.net running. I'm told that SCHED_ULE is the greatest
>thing since sliced bread for some compute load or other (details are
>scarce), but I (fortunately) don't often have to run heavy server
>type loads; and for everyday use (even without distributed.net
>running), SCHED_4BSD is my choice by far. It's too bad I can't run
>freebsd_update with it, though.
>
I gave up on ULE during 8-STABLE. I had tried tinkering with
kern.sched.preempt_thresh as recommended, as well as some more extreme
values, but I couldn't see any improvement. Some values may have made
performance even worse. The last straw for me, however, was when I
discovered that ULE happily scheduled *idle* priority processes at times
when both CPU threads on a P4 Prescott were tied up by 100% CPU-bound
(mprime) threads at normal priority niced to 20. Idle priority tasks
should *only* run when no higher priority tasks are available to run for
all CPU threads. The 4BSD scheduler handles this situation properly.
Now I'm running 10.3-STABLE on a QX9650, and I haven't tested ULE
on it to see whether it's still as flawed. If and when I get a machine
with a multi-cored, hyperthreaded CPU or perhaps a board with multiple
CPU chips, then I may worry about the multi-level affinity stuff that
ULE was supposedly designed for enough to bother testing it. But for
now, I can't see any advantage in it for my current machine.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************