From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D65092D5946 for ; Mon, 2 Feb 2026 09:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770025199; cv=none; b=XVxaRGuPVAxXZTpV6OcFBHiL30dBPgzs5aaXnCbkO75ZB92Dov6Ct0J4dTZUumWI0nOpRT6Fi+0Lx07vFVu/F7HmH7eTIbVF7s/437ixMEVQbOdIHcNkLD70NNS9RKW9NbwtMuQI5Hsw5PPciI8tenLwfU4l0pDHwtKPEcdxsiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770025199; c=relaxed/simple; bh=2dP8qkWmAcbDkkqUveD7xUOrsKCBltLZPmkIu8ifvnk=; h=Date:Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Gado7mFhMFcn1C2Zuk0S9O5v2Zi+yWqK8AirBkBaj8GCr4dmBMuUxuYPP/dhXY6flXg0W/HU3JLnU6xn32MO6kyYMGRwt0itde1qcPYkziHLpC/tLt1gywkc02x43c+yKhNgcvUL7OZZBDNxFl/6nHgKzv8GbD7cs8LsopFc2IM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lifeHL+M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lifeHL+M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 999AAC116C6; Mon, 2 Feb 2026 09:39:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770025199; bh=2dP8qkWmAcbDkkqUveD7xUOrsKCBltLZPmkIu8ifvnk=; h=Date:From:To:Cc:Subject:References:From; b=lifeHL+MFrZ6TVs2nOa9GArihivYl/E4v6Rh4ISYEPQfl0ZdHu6Af9WN2ptvwiSdW gAHvL1NWan8TpOJ9rgCfpaAZzqOeXl4eZQ43XMcdDJe+EDJC3jDAbQjB+ns3VPoEn2 MQPDi6DYTm/imw8Gnt4WBpN1RBiLV1KTyl6APA2qi8Zv+tK0SJGKe2gl/loOCvlnpF lPLbNR59LJlO1FDZnT5q6DGAp+1MZl57kwA0lEdf2bQHI3b67SsM2PsPtKueGLiyan xzVEUU7HWz2T9b0oOUTGsZ6MJl1G7RmaQye96gERkowxn+UYzQ5ua57klhsfHruEri 3dW5As8+b5a1w== Date: Mon, 02 Feb 2026 10:39:55 +0100 Message-ID: <20260201192835.100194627@kernel.org> User-Agent: quilt/0.68 From: Thomas Gleixner To: LKML Cc: Ihor Solodrai , Shrikanth Hegde , Peter Zijlstra , Mathieu Desnoyers , Michael Jeanson Subject: [patch V2 4/4] sched/mmcid: Optimize transitional CIDs when scheduling out References: <20260201192234.380608594@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 During the investigation of the various transition mode issues instrumentation revealed that the amount of bitmap operations can be significantly reduced when a task with a transitional CID schedules out after the fixup function completed and disabled the transition mode. At that point the mode is stable and therefore it is not required to drop the transitional CID back into the pool. As the fixup is complete the potential exhaustion of the CID pool is not longer possible, so the CID can be transferred to the scheduling out task or to the CPU depending on the current ownership mode. The racy snapshot of mm_cid::mode which contains both the ownership state and the transition bit is valid because runqueue lock is held and the fixup function of a concurrent mode switch is serialized. Assigning the ownership right there not only spares the bitmap access for dropping the CID it also avoids it when the task is scheduled back in as it directly hits the fast path in both modes when the CID is within the optimal range. If it's outside the range the next schedule in will need to converge so dropping it right away is sensible. In the good case this also allows to go into the fast path on the next schedule in operation. With a thread pool benchmark which is configured to cross the mode switch boundaries frequently this reduces the number of bitmap operations by about 30% and increases the fastpath utilization in the low single digit percentage range. Signed-off-by: Thomas Gleixner --- kernel/sched/sched.h | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -3902,12 +3902,31 @@ static __always_inline void mm_cid_sched static __always_inline void mm_cid_schedout(struct task_struct *prev) { + struct mm_struct *mm = prev->mm; + unsigned int mode, cid; + /* During mode transitions CIDs are temporary and need to be dropped */ if (likely(!cid_in_transit(prev->mm_cid.cid))) return; - mm_drop_cid(prev->mm, cid_from_transit_cid(prev->mm_cid.cid)); - prev->mm_cid.cid = MM_CID_UNSET; + mode = READ_ONCE(mm->mm_cid.mode); + cid = cid_from_transit_cid(prev->mm_cid.cid); + + /* + * If transition mode is done, transfer ownership when the CID is + * within the convergence range to optimize the next schedule in. + */ + if (!cid_in_transit(mode) && cid < READ_ONCE(mm->mm_cid.max_cids)) { + if (cid_on_cpu(mode)) + cid = cid_to_cpu_cid(cid); + + /* Update both so that the next schedule in goes into the fast path */ + mm_cid_update_pcpu_cid(mm, cid); + prev->mm_cid.cid = cid; + } else { + mm_drop_cid(mm, cid); + prev->mm_cid.cid = MM_CID_UNSET; + } } static inline void mm_cid_switch_to(struct task_struct *prev, struct task_struct *next)