From nobody Mon Mar 27 22:23:42 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PlnVz3Pygz42948 for ; Mon, 27 Mar 2023 22:27:23 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PlnVy6W2Bz3vtT; Mon, 27 Mar 2023 22:27:22 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 32RMR7BM039300 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 Mar 2023 00:27:07 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from uucp@localhost) by uucp.dinoex.org (8.17.1/8.17.1/Submit) with UUCP id 32RMR7Ds039299; Tue, 28 Mar 2023 00:27:07 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 32RMPjdx029781 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Tue, 28 Mar 2023 00:25:45 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.17.1/8.17.1) with ESMTPS id 32RMNgkL014177 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 Mar 2023 00:23:43 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.17.1/8.17.1/Submit) id 32RMNg2j014176; Tue, 28 Mar 2023 00:23:42 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Tue, 28 Mar 2023 00:23:42 +0200 From: Peter To: freebsd-hackers@freebsd.org Cc: Mateusz Guzik , Matthias Andree Subject: Re: Periodic rant about SCHED_ULE Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Tue, 28 Mar 2023 00:27:10 +0200 (CEST) X-Rspamd-Queue-Id: 4PlnVy6W2Bz3vtT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Quoting Mateusz Guzik : >When deciding what to run, 4BSD uses runq_choose which iterates all >queues from the beginning. This means threads of lower priority keep >executing before the rest. In particular cpu hog lands with a high >priority, looking worse than make -j 8 buildkernel and only running >when there is nothing else ready to get the cpu. While this may sound >decent, it is bad -- in principle a steady stream of lower priority >threads can starve the hogs indefinitely. Ideally, while starving, the priority of that hog should occasionally get re-calculated, until it is low enough to run it again. Not sure if that actually happens. >The problem was recognized when writing ULE, but improperly fixed -- >it ends up distributing all threads within given priority range across >the queues and then performing a lookup in a given queue. Here the As I did understand it, the ULE run-queue is circular and works like a revolver barrel. So yes, once in a while everybody gets a shot. >problem is that while technically everyone does get a chance to run, >the threads not using full slices are hosed for the time period as >they wait for the hog *a lot*. Yes, exactly. The hog stays at the pole position until they use up their quantum.