From owner-freebsd-stable@freebsd.org Thu Nov 3 15:33:39 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0CC5C2D78B for ; Thu, 3 Nov 2016 15:33:39 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.lonestar.org (ol.sdf.org [192.94.73.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ol.sdf.org", Issuer "ol.sdf.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9977213B6 for ; Thu, 3 Nov 2016 15:33:39 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (norge.freeshell.org [192.94.73.17]) by sdf.lonestar.org (8.15.2/8.14.5) with ESMTPS id uA3FXIbI022098 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 3 Nov 2016 15:33:19 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id uA3FXIma020158; Thu, 3 Nov 2016 10:33:18 -0500 (CDT) From: Scott Bennett Message-Id: <201611031533.uA3FXIma020158@sdf.org> Date: Thu, 03 Nov 2016 10:33:18 -0500 To: freebsd-stable@freebsd.org, george+freebsd@m5p.com Subject: Re: huge nanosleep variance on 11-stable User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:33:40 -0000 On Wed, 2 Nov 2016 10:23:24 -0400 George Mitchell wrote: >On 11/01/16 23:45, Kevin Oberman wrote: >> On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening >> 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 * **********************************************************************