Date: Thu, 03 Nov 2016 10:33:18 -0500 From: Scott Bennett <bennett@sdf.org> To: freebsd-stable@freebsd.org, george+freebsd@m5p.com Subject: Re: huge nanosleep variance on 11-stable Message-ID: <201611031533.uA3FXIma020158@sdf.org>
next in thread | raw e-mail | index | archive | help
On Wed, 2 Nov 2016 10:23:24 -0400 George Mitchell <george+freebsd@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@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 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201611031533.uA3FXIma020158>