From nobody Mon Jun 8 15:36:50 2026 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAAD43DFC7E for ; Thu, 28 May 2026 13:12:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779973971; cv=none; b=XU+2YUXRZaRFk7ReFoIe+nwKtzTq04zQrwyw5eyyE68dtUgraNetza3bZ8O0g8qdDXIlvMkz7w7oy/gKwSZKW5+QYvy+63UkkXriZGcP7qbUtFSlRhtI6B9qXH3JQjdf8GhIkosVwK0ZjeP0aMHBrWm5zkTYdAgPBCWiTmmOzc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779973971; c=relaxed/simple; bh=i66rAQ3zg6Hqrj65fMCkYDh2ZQF0MQhtxxmF9pxUAYo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W++Q0d1HMH3F6+T4rhHAOw8TRtVzoZ95DqKS/XKF3zBkBlp9H2HU0Oz2VVvnH9XWFwhfbRzmAsbHKgvcB7H+tyP497RDEdog6ON9W7EfMlzRte81yZB+zgIl7vYBLR1RV/WL4GD0nKvIyv26V4AfLo0V6WDIiH/he64+FkBPsuI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fPCAmbwx; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fPCAmbwx" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-841882f8f4bso2104525b3a.0 for ; Thu, 28 May 2026 06:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779973969; x=1780578769; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zcfHENymJGZHtdeIVFKzzwGhB5oFtix9tlsZ2996z0M=; b=fPCAmbwxMK2/RR6MFNyoymJXt3tNF4QEu14jwRb8JmY0HgY7fDb/Ra5FfzvsTajy/Z U/S70AOJITtzGEmhO7Mqsx+oWOQTKM+QJUI2kdxrRJkma53kBeYym/kgg5KBgQqiVRli VvXoTRBlbpU1QnSeggTOcmlTdtjrLWbKvhBKCBmWCrxdovVvHLK8vVU2I6m5ABmUOCWA 6ShWuyNZ+bHbZKZVZ1ZMSdedwUGNEdMw/DwGppo7aUqo3aUrudQ5NXGg8oX1C2qchskZ OthsS7JplmRPvNfYAUU4yeVMC+OkMETWkAg4rRaQU6+QTyfcFt+IuMkFi8G3uyQDpZfR GXDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779973969; x=1780578769; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zcfHENymJGZHtdeIVFKzzwGhB5oFtix9tlsZ2996z0M=; b=dnMRPrjh5DG3f5y+7Pwb0j1O/nnv0gaz0wxHspfN+OIDb5bnHa2CzmYL4Qq5xrptK7 n3TcfY53uALvgiqBbUWZiA8zqUOia7Eev2mNSnxNVR6wgt8trXNL8DJPVPkUz8n395NQ Qu7GB/BXJ6lwZtnT9m6rSbqcvB6V2ezXozU3pSjp1rnxThmI5sxZ1N/kA/hC4z5Y4ub4 vadlp49aCpnGWsGTai/c82dZZJyCSb1pkVGPEU6Okb3MezRb6eKiSZH+PxaQfmFMKtok Olfm3Jl7lXDHyzNgPxxbaTDHWJ0OfEWyqTKT1FfsxpwpdP9sr7oEKhn3l2H7L6iZzoRm e+SQ== X-Forwarded-Encrypted: i=1; AFNElJ/+8LG8vOIXcaNkMDTtD/NQzdxDNY4QI9WPLa+vjAHoweFLZKKA9QEq6RnZTm+i9tk1aNUtErE0mg83gbE=@vger.kernel.org X-Gm-Message-State: AOJu0YxkDt0gnVogBFhJ2zQTxjP5sWgx5Zb22vIpfCmTW14oiPjQs4gT SV1uQ8bTiwkYICbU5x6IxRkOISc5GWIJf5oxQqTP/Z9oyQSIS0Bv2/3j X-Gm-Gg: Acq92OEN2lXueeZy13yITanHtheGkSTXbTT26sST6EB8VHwahy6p68Gm+N1MM5DepMX g2t+94dJ1nvlryAiA52YzWkoKkU3SL5spf3gVwjvIc7X1JzRVpHkgnOwoq3iO8Ln61Wcm/AaGZg 2ZsvlYXm7uEENekSuqu5TNpKqb3qHl6oc0E97GBZsCY89/0sIbz+DHJW4up8Gxt9/E1xvNoDyTh HjgFjwne4W0SEiYdKAJ+jjN7nicCNgtXzpyKLHzHjsrxUuaCfEiTqxcy+hiab3RNNwChom4aWYN GcWOVH/g8e7OYDFhiBKHLHwLeq+MrlISF8HHvYZfjIPTmYleriehhQqSuyiu3A6DKjvimQvGsW3 eDyOs1hpBwJYKi0NAs7NoGIN3e5i2FcEpkVlT+m/U01sNDUxxMxmPUTXsXTJ388kQ6OXhwefdIh zhTjykVXmq4xTPcyP+WEWpz+zafn9hK/XEl+C0hmEW+Pk= X-Received: by 2002:a05:6a00:2d8e:b0:82c:d7c4:4c5c with SMTP id d2e1a72fcca58-8415f5db43cmr27481058b3a.20.1779973968589; Thu, 28 May 2026 06:12:48 -0700 (PDT) Received: from VM-0-14-ubuntu.. ([124.156.198.44]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-841d6d60d07sm6710443b3a.0.2026.05.28.06.12.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 06:12:46 -0700 (PDT) From: quzicheng315@gmail.com To: peterz@infradead.org Cc: arighi@nvidia.com, brho@google.com, bsegall@google.com, changwoo@igalia.com, dietmar.eggemann@arm.com, haoluo@google.com, joshdon@google.com, juri.lelli@redhat.co, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, quzicheng315@gmail.com, quzicheng@huawei.com, rostedt@goodmis.org, sched-ext@lists.linux.dev, tanghui20@huawei.com, tj@kernel.org, vincent.guittot@linaro.org, void@manifault.com, vschneid@redhat.com, zhangqiao22@huawei.com Subject: [PATCH v3] sched/fair: Rebuild load weight when switching to fair Date: Thu, 28 May 2026 21:12:38 +0800 Message-ID: <20260528131238.3879110-1-quzicheng315@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260528092535.GC343181@noisy.programming.kicks-ass.net> References: <20260528092535.GC343181@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zicheng Qu Tasks that run outside fair may not keep p->se.load in sync with their current scheduling policy and static priority. sched_ext, for example, uses p->scx.weight as the active scheduling weight, so p->se.load can be stale when a task moves back to fair. The fair_sched_class expects the sched_entity load weight to be valid before the task is enqueued. Rebuild it from fair's switching_to hook, which runs after the class has been changed to fair and before enqueue, so both sched_ext disable and SCHED_EXT to SCHED_NORMAL transitions get a native fair load weight. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Suggested-by: Peter Zijlstra Signed-off-by: Zicheng Qu Acked-by: Tejun Heo --- Changes in v3: - Move the rebuild into fair's switching_to hook, as suggested by Peter. This lets fair prepare its own state before enqueue and avoids adding a sched_ext/fair-specific fixup to the generic sched_change_end() path. Changes in v2: - Move the fix from scx_root_disable() to the class switch path so it also covers partial-mode SCHED_EXT to SCHED_NORMAL transitions through sched_setscheduler(). Andrea identified this missing case in the v1 discussion. kernel/sched/fair.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 3ebec186f982..3a21ceefcadf 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13837,6 +13837,15 @@ static void switched_from_fair(struct rq *rq, stru= ct task_struct *p) detach_task_cfs_rq(p); } =20 +static void switching_to_fair(struct rq *rq, struct task_struct *p) +{ + /* + * Tasks may come from classes that don't keep se.load up to date. + * Rebuild it before the task is enqueued. + */ + set_load_weight(p, false); +} + static void switched_to_fair(struct rq *rq, struct task_struct *p) { WARN_ON_ONCE(p->se.sched_delayed); @@ -14233,6 +14242,7 @@ DEFINE_SCHED_CLASS(fair) =3D { .prio_changed =3D prio_changed_fair, .switching_from =3D switching_from_fair, .switched_from =3D switched_from_fair, + .switching_to =3D switching_to_fair, .switched_to =3D switched_to_fair, =20 .get_rr_interval =3D get_rr_interval_fair, --=20 2.53.0