From owner-freebsd-stable@freebsd.org Wed Apr 4 20:13:27 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 3B9BEF72D9A for ; Wed, 4 Apr 2018 20:13:27 +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 90B1B71582 for ; Wed, 4 Apr 2018 20:13:26 +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 w34KD5VE018433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 22: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 w34KD5fl018432 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 22: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 w34JaE00046332 for ; Wed, 4 Apr 2018 21:36:14 +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 w34JY3Hh046061 for ; Wed, 4 Apr 2018 21:34:04 +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 w34JY3Yl046056 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 21:34: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, 4 Apr 2018 21:25:49 +0200 Organization: even some more stinky socks Message-ID: References: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 19:26:26 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="44897"; 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: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> 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, 04 Apr 2018 22: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, 04 Apr 2018 20:13:27 -0000 Andriy Gapon wrote: > On 04/04/2018 03:52, Peter wrote: >> Lets run an I/O-active task, e.g, postgres VACUUM that would >> continuousely read from big files (while doing compute as well [1]): > > Not everyone has a postgres server and a suitable database. > Could you please devise a test scenario that demonstrates the problem and that > anyone could run? > Andriy, and maybe nobody anymore has such old system that is CPU-bound instead of IO-bound. I'd rather think about reproducing it on my IvyBridge. I know for sure that it is *not* specifically dependent on postgres. What I posted was the case when an endless-loop piglet starves a postgres VACUUM - and there we see a very pronounced effect of almost factor 100. When I first clearly discovered it (after a long time of belly-feeling that something behaves strange), it was postgres pg_dump (which does compression, i.e. CPU-bound) as the piglet starving an bacula-fd backup that would scan the filesystem. So, there is a general rule: we have one process that is a CPU-hog, and another process that does periodic I/O (but also *some* compute). and -important!- nothing else. If we understand the logic of the scheduler, that information should already suit for some logical verification *eg* - but I will see if I get it reprocuved on the IvyBridge machine and/or see if I get a testcase together. May take a while. P.