From owner-freebsd-stable@freebsd.org Wed Apr 18 18:13:20 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85F64F9F407 for ; Wed, 18 Apr 2018 18:13:20 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F01A671DFB for ; Wed, 18 Apr 2018 18:13:19 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w3IID6lP006531 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 18 Apr 2018 20:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w3IID6Cj006530 for freebsd-stable@FreeBSD.ORG; Wed, 18 Apr 2018 20:13:06 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w3II5Zk3048953 for ; Wed, 18 Apr 2018 20:05:35 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w3II438K048755 for ; Wed, 18 Apr 2018 20:04:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w3II43xw048754 for freebsd-stable@FreeBSD.ORG; Wed, 18 Apr 2018 20:04:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Wed, 18 Apr 2018 19:59:39 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> <20180417065617.GA95646@klump.hjerdalen.lokalnett> <20180417232016.2008438c.ebfe@inbox.ru> <2a68cfd7-6823-296d-0392-c9b12c66f6e0@m5p.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 18 Apr 2018 17:59:39 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="47730"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 X-Mozilla-News-Host: news://localhost In-Reply-To: <2a68cfd7-6823-296d-0392-c9b12c66f6e0@m5p.com> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 18 Apr 2018 20:13:08 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 18:13:20 -0000 Hi all of You, thank You very much for Your commenting and reports! From what I see, we have (at least) two rather different demands here: while George looks at the over-all speed of compute throughput, others are concerned about interactive response. My own issue is again a little bit different: I am running this small single-CPU machine as my home-office router, and it also runs a backup service, which involves compressing big files and handling an outgrown database (but that does not need to happen fast, as it's just backup stuff). So, my demand is to maintain a good balance between realtime network activity being immediately served, and low-priority batch compute jobs, while still staying responsive to shell-commands - but the over-all compute throughput is not important here. But then, I find it very difficult to devise some metrics, by which such a demand could be properly measured, to get compareable figures. George Mitchell wrote: > I suspect my case (make buildworld while running misc/dnetc) doesn't > qualify. However, I just completed a SCHED_ULE run with > preempt_thresh set to 5, and "time make buildworld" reports: > 7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w > Much closer to SCHED_4BSD! I'll try preempt_thresh=0 next, and I > guess I'll at least try preempt_thresh=224 to see how that works > for me. -- George > I found that preempt_thresh=0 cannot be used in practice: When I try to do this on my quadcode desktop, and then start four endless-loops to get the cores busy, the (internet)radio will have a dropout every 2-3 seconds (and there is nothing else running, just a sleeping icewm and a mostly sleeping firefox)! So, the (SMP) system *depends* on preemption, it cannot handle streaming data without it. (@George: Your buildworld test is pure batch load, and may not be bothered by this effect.) I think the problem is *not* to be solved by finding a good setting for preempt_thresh (or other tuneables). I think the problem lies deeper, and these tuneables only change its appearance. I have worked out a writeup explaining my thoughts in detail, and I would be glad if You stay tuned and evaluate that. P.