From nobody Tue Jul 21 02:26:53 2026 X-Original-To: dev-commits-src-main@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 4h41VQ1lWbz6lM2f for ; Tue, 21 Jul 2026 02:26:54 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4h41VQ0tCCz3mvT for ; Tue, 21 Jul 2026 02:26:54 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1784600814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=k6Iw5YOmRZdG+LBHEE7b84LgNYA8D5P349IKbxReHRk=; b=v8PTLtt34onc4RxS59njrK4Y5H3u4qeuNhTuc2q17IQWfyeftMmbTJpbEpxnr8IQ+JQjI/ hdW6eMuUYY+FikW6vqjucIQNpX1eRDbiA2WUxMuCvDkSGcSGLLBxCg09FNaZd6bynHVghb YDptdB/hZnnK/zPbe5dW3R4H47J8RYqgIcaf4kvptJReLJUCklj1E1izI3DAQY5gWG963S tJ/Yuf2H+oOwVeatFC+qojwBaWn9hL01mQc7VCQWjhGsT1Wh39MJ+a2bzlLVoidipUyQ/b rUYYmAgxVtognmyNXjaj+tp90ddEFO5ML2frZqAHttmmr54ozixTdz8CE1CqRQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1784600814; a=rsa-sha256; cv=none; b=Jfm1BH8QeR40JC58ELMPAJEs9WKWzfy33fU2xcdDE09C5qbwOGgsnoKmlOOf9KC5TtNYtX s+gi0Ds0EzIiadtxd13j9te/ZB5qXxGJtaLBd/JtmsMi1G71ey+Io0fpc5JVz6NmVrgXh/ 8g3qSPg8qNdlKY8hNuCEw6Qn4ZuFxHwJYo+ZQhV7rLS7HH9VEIOGkVyoD89Qbt3SuIRxNS XfW+4BKsO/ZQcLwtyg6Khwu+a0yFSowlH6DaUIaDZIMp72bCA/WwN9DU3rzEha7DHmwp/g m9VwrnF3BFC/v6QRTyd32NBhEtqVsNKQk5Qy1bytnhQxlyj6srEg28Mt7BhwNQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1784600814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=k6Iw5YOmRZdG+LBHEE7b84LgNYA8D5P349IKbxReHRk=; b=bGLUJSdknzeXxB+OLt0LrKmNlzfvE6B1ReWSMSFj6A6rjAmtouwf1EH17D2YpaxSV0+5IB w7eITjkeQaMq0EsEJpj/0NJZIbFCxMIXc315h0PMFOMLG1oAqBT4DS7GNwlzflBX5k695V zmF240UARrksqtvw3cYQqjPKAoQGF6JBF4Qh3XfqluWYCHJzRTVgITJsUTd/vfbquEtdS7 5bbJRuyngZUdPx8+UUv/V40VXfEkyrS3reTB1voyEoaC7dBN3KytR7ZAq4xO+EpV3WAT5/ m/z8KvIYO/jOz2k2KsnwHypqcykXXi5cVHNW2lTa10CMyEkTlWeqsJXvjXav9Q== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id 4h41VP62V8zDJM for ; Tue, 21 Jul 2026 02:26:53 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from git (uid 1279) (envelope-from git@FreeBSD.org) id 21c87 by gitrepo.freebsd.org (DragonFly Mail Agent v0.13+ on gitrepo.freebsd.org); Tue, 21 Jul 2026 02:26:53 +0000 To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: Olivier Certner Subject: git: e8dec0038bd9 - main - sched_4bsd: Fix conflating priority of differently-niced CPU-bound threads List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: olce X-Git-Repository: src X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e8dec0038bd95f6d940afa19b4d101f466280fd6 Auto-Submitted: auto-generated Date: Tue, 21 Jul 2026 02:26:53 +0000 Message-Id: <6a5ed8ed.21c87.393dab61@gitrepo.freebsd.org> The branch main has been updated by olce: URL: https://cgit.FreeBSD.org/src/commit/?id=e8dec0038bd95f6d940afa19b4d101f466280fd6 commit e8dec0038bd95f6d940afa19b4d101f466280fd6 Author: Olivier Certner AuthorDate: 2026-06-13 13:09:42 +0000 Commit: Olivier Certner CommitDate: 2026-07-21 02:24:10 +0000 sched_4bsd: Fix conflating priority of differently-niced CPU-bound threads We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any value in the timeshare range") in order to use more than a fixed number (40) of all the available priority levels in the timeshare range (136 before the 256-queue runqueue work, 224 now) to take into account the number of ticks a thread has run ('ts_estcpu'). In the computation of a new thread's priority (resetpriority()), in addition to the "ticks running" contribution, the final priority also includes a "nice" value contribution. The final value is clamped into the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range. Problem is that the new "ticks running" contribution now can lead to a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all out-of-bound values. In particular, this can conflate CPU-hungry threads. With at least two of them competing on the same CPU, with an increase of 'ts_estcpu' of ~64 per second (stathz being 127) and the minimal decay of 4/5 (load average 2 or more), both threads will easily reach the current clamping of 224 (+ PRI_MIN_TIMESHARE), and be considered indifferently by the scheduler. Fix this problem by ensuring that the maximum contribution of 'ts_estcpu' (via ESTCPULIM()) cannot exceed the timeshare range of priorities when the nice contribution is added to it, so the nice contribution continues to have an effect on CPU-bound threads. Introduction of the nice term in ESTCPULIM() (then NICE_WEIGHT * PRIO_MAX) has been done in commit bdf423572ee3 ("Scheduler fixes equivalent to the ones logged in the following NetBSD commit...") and does not appear to have made any real sense even then. Fixes: bdf423572ee3 ("Scheduler fixes equivalent to the ones logged in the following NetBSD commit...") Fixes: eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any value in the timeshare range") MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57826 --- sys/kern/sched_4bsd.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c index 53e32026029d..f86dcda218a4 100644 --- a/sys/kern/sched_4bsd.c +++ b/sys/kern/sched_4bsd.c @@ -78,8 +78,8 @@ #define NICE_WEIGHT 1 /* Priorities per nice level. */ #define ESTCPULIM(e) \ min((e), INVERSE_ESTCPU_WEIGHT * \ - (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) + \ - PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) \ + (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE - \ + (PRIO_MAX - PRIO_MIN) * NICE_WEIGHT) \ + INVERSE_ESTCPU_WEIGHT - 1) #define TS_NAME_LEN (MAXCOMLEN + sizeof(" td ") + sizeof(__XSTRING(UINT_MAX))) @@ -596,11 +596,13 @@ resetpriority(struct thread *td) if (td->td_pri_class != PRI_TIMESHARE) return; - newpriority = PUSER + + newpriority = PRI_MIN_TIMESHARE + td_get_sched(td)->ts_estcpu / INVERSE_ESTCPU_WEIGHT + NICE_WEIGHT * (td->td_proc->p_nice - PRIO_MIN); - newpriority = min(max(newpriority, PRI_MIN_TIMESHARE), - PRI_MAX_TIMESHARE); + KASSERT(PRI_MIN_TIMESHARE <= newpriority && + newpriority <= PRI_MAX_TIMESHARE, + ("Out-of-bounds priority, probably 'ts_estcpu' not clamped " + "correctly, see ESTCPULIM()")); sched_user_prio(td, newpriority); }