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 D2878F9F402 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 [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 39E9371DF8 for ; Wed, 18 Apr 2018 18:13:18 +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 w3IID5JG006526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 18 Apr 2018 20:13:05 +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 w3IID5lK006525 for freebsd-stable@FreeBSD.ORG; Wed, 18 Apr 2018 20:13:05 +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 w3II5Zk1048953 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 w3II41LY048747 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 w3II41gR048744 for freebsd-stable@FreeBSD.ORG; Wed, 18 Apr 2018 20:04:01 +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:57:12 +0200 Organization: even some more stinky socks Message-ID: <778b2c90-3ff3-1586-317f-25ba28655e1b@citylink.dinoex.sub.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 In-Reply-To: <20180417232016.2008438c.ebfe@inbox.ru> 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:06 +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 EBFE via freebsd-stable wrote: > On Tue, 17 Apr 2018 09:05:48 -0700 > Freddie Cash wrote: > >> # Tune for desktop usage >> kern.sched.preempt_thresh=224 >> >> ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor >> (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU. > > For interactive tasks, there is a "special" tunable: > % sysctl kern.sched.interact > kern.sched.interact: 10 # default is 30 > % sysctl -d kern.sched.interact > kern.sched.interact: Interactivity score threshold > > reducing the value from 30 to 10-15 keeps your gui/system responsive, > even under high load. Yes, this may improve the "irresponsive-desktop" problem. Because threads that are scored interactive, are run as realtime threads, ahead of all regular workload queues. But it will likely not solve the problem described by George, having two competing batch jobs. And for my problem as described at the beginning of the thread, I could probably tune so far that my "worker" thread would be considered interactive, but then it would just toggle between realtime and timesharing queues - and while this may make things better, it will probably not lead to a smooth system behaviour. P.