From owner-freebsd-stable@freebsd.org Sat Apr 7 01:13:35 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 6D097F971A3 for ; Sat, 7 Apr 2018 01:13:35 +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 AF3D87FE6E for ; Sat, 7 Apr 2018 01:13:34 +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 w371D3kA002718 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 7 Apr 2018 03:13:04 +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 w371D3jF002717 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 03:13:03 +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 w370srdE036673 for ; Sat, 7 Apr 2018 02:54:53 +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 w370s2Hg036587 for ; Sat, 7 Apr 2018 02:54: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 w370s2jh036585 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 02:54:02 +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: Sat, 7 Apr 2018 02:47:56 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> <5AC5BA42.1010006@grosbein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 7 Apr 2018 00:48:10 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="35506"; 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 In-Reply-To: <5AC5BA42.1010006@grosbein.net> 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]); Sat, 07 Apr 2018 03:13:05 +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: Sat, 07 Apr 2018 01:13:35 -0000 Eugene Grosbein wrote: > I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD. Nitpicking: it is not a single core system, it's a dual that for now is equipped with only one chip, the other is in the shelf. But seriously, I am currently working myself through the design papers for the SCHED_ULE and the SMP stuff, and I tend to be with You and George, in that I do not really need these features. Nevertheless, I think the system should have proper behaviour *as default*, or otherwise there should be a hint in the docs what to do about. Thats the reason why I raise this issue - if the matter can be fixed, thats great, but if we come to the conclusion that small/single-core/CPU-bound/whatever systems are better off with SCHED_4BSD, then thats perfectly fine as well. Or maybe, that those systems should disable preemption? I currently don't know, but i hope we can figure this out, as the problem is clearly visible. P.