From nobody Mon Sep 28 11:39:33 2026 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 CC91A381E9B for ; Sat, 22 Aug 2026 10:59:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787396381; cv=none; b=EkkZGDx/HM7zbm9swCvRQLhpZy7kwfM+LnjsoEjxeBCF1PziQwOKblk4CLj4kA2NEGnmpQ01XUyclnDGkf5UyHoHqwdmjG7yd+vYVskoyq5AWxyDedrCWJzZG7tkJ3nxAl4COAhkzLrDUxZCU2utOnSCkWiqAnzPFHSBHEsdeBY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787396381; c=relaxed/simple; bh=Jzb1FkBgX16Uv6nfN1xr4kaELkkIYRjQAcST3tFuI2U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=UXGhBBmV6MNn+4D3tUJIHfrDTIgZwijwRTEXOrCrguPYVuJAr9YASjoGgHESxjgX/lOzEH4vbdJT2JHiYeGusEpqSGiWyezcITry6fcfzudHAVP+BtT2wV4c0DoK3lXcndGIKk/XzG0NlP0dA590M8D0XgUM4/d0O/sRg3jTWeA= 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=n8WfhM+H; arc=none smtp.client-ip=209.85.216.41 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="n8WfhM+H" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-395ea741d07so190542a91.1 for ; Sat, 22 Aug 2026 03:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787396379; x=1788001179; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=pfaC71DUqgkXzYErANu3jprwmokOPCxInFaqET/XNXw=; b=n8WfhM+HO2BgkKkmwR3GYK0S1NDoLdUrZhoekiWjaO13VecUbtYMCqBCJVNmG7UcMx SwfoyKD1iP1CmfDNB7VREbS8V30kLtXz7Qa8S96ar/2BtMCpc9ZhiOQ+NiOdS6DEaVdW mBWWEb4dZ3D4kV7BhL4zwcXZF1dh3J7ubAS2hKwY77Lt1drVbJVPO3vOd2OyDjOu+zkf bckus10pEqXdxQGyPXe+JQ+CSP2j+SlSsMP8rEhdyyYYZcVamDjKwjr5F7h+qJIaaPo5 AcaZ4T3yGDvUmHk36xzTRg714/aEGXZAfwq2K7x5KPos3N5yiG2gfpXZc+mnC2Hhtbt1 U3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787396379; x=1788001179; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pfaC71DUqgkXzYErANu3jprwmokOPCxInFaqET/XNXw=; b=flf/qphDDbGAYADEQK/ciUKAD2ive0PA/U1kL0MqZapgeAAdMWmOysmGoeFctkl6+t 9Y2rXc4dQw3qcaDq62bA3V6IMNEwU5wcELZCDBL1rHd/S3kwcj72v6qasBNIiEAGJazc 5JfVcB3KqWCizNjCD/qya64zuaEZsIET9390+/CommMSVnMUsYdDfRpcwBMs3rs8p+y4 eVu/rHIsvOuNOVOHTbVCdRs6O9fN3OtsOb54tWJnM4d61PhabMQBun2peShKO3Mu9H15 7/4XE+we7jP04kcpXThzxyOb5VQVEq/3vCrNusADqDp3TrQISLG/0KuVyuBl7ViG1xXO Tezg== X-Forwarded-Encrypted: i=1; AHgh+Ro/9Otd24TFT7Ya7N3td2VsbUeB5U6xzZPD0fmJZHojusQMBJyEcnCZrr3kzr4ACEIXLp6rWjiGdU8wZxo=@vger.kernel.org X-Gm-Message-State: AFuF++k3fDUxJb6rV9TG6Y8ecwZCGMqHmQ2lmga6ccT4V3cTaw1pBy7N cb2kHAaA2pD94IrNRHJY+WQBnWNMQ8Ob/W9WeVswEBLXZ7qJliPFt6cn X-Gm-Gg: AR+sD13g+Y/CRZb7N9tLH2DOvw//kh5+PZo8o2SHa7zaCr1VuUFmQefzwXXO61+JzEB ItRflOUBwrQwRkDfRV3+2UpcLnugo0T//7fuD66EiwKHcpbaF9WAmGIAwbzwSeCmSxquWfzjaxA REiIowSPKgzHOhzn0bIsmyjH8bDu6RHnnWUP8jLzatNrJ2AqAVwOdpPVRkshA84pPXLfY93ubky OBUeRCd2zWhVT5wxNRbI7RqxRoJEX26061or1l9/d6HB9KvI7jXLpCpsUyXI0yTVR48WnnV7e6J 4pMSk9GorJbukHbzpYFiJP0T6DUSgBVyFtxouDE3/JdHS927/6ber6IA/CD4AN8ZboMcgFPL2in cXt+X+cVH+MncP3t2Txk21SllXN4uReyzReI8ezSMJSAAY/QPsTModMllG1IYdHal41IL8QG+ez lCvnCfsWXpicxPl0PHhGJeitHMGGQdl0AYMSO2j9tBqqigiGez91CkM5gcNfltWLpTqRk6UprgF S2+rXR1RlwiGTc= X-Received: by 2002:a17:90a:f945:b0:38f:aab1:5148 with SMTP id 98e67ed59e1d1-395c35b75efmr22922532a91.13.1787396378984; Sat, 22 Aug 2026 03:59:38 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-395e4a1597csm2377953a91.13.2026.08.22.03.59.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Aug 2026 03:59:38 -0700 (PDT) From: Zhan Xusheng To: Vincent Guittot , Peter Zijlstra , Ingo Molnar Cc: Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com, Zhan Xusheng Subject: [PATCH] sched/fair: Use update_curr_eevdf() for the remaining root cfs_rq callers Date: Sat, 22 Aug 2026 18:59:30 +0800 Message-ID: <20260822105930.2352761-1-zhanxusheng1024@gmail.com> X-Mailer: git-send-email 2.43.0 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: Zhan Xusheng pick_task_fair() and yield_task_fair() call update_curr(&rq->cfs) to bring curr up to date before they look at the eevdf state. With cgroups that does not happen: update_curr() reads ->h_curr, which on the root cfs_rq is the top level group entity, and returns at the !entity_is_task() check before touching vruntime. Both then read ->curr, so the guard and the update disagree about which entity they mean. Counting how often ->h_curr and ->curr differ at pick_task_fair(), on one CPU for 10s with three busy tasks and one 200us-periodic task: all tasks in the root cgroup 43321 calls, 0 no-ops busy tasks in G0, periodic in G1 45211 calls, 45193 no-ops Whether that matters depends on what precedes the pick. Since commit 68e37487810a ("sched/fair: Fix flat hierarchy") the tick and enqueue/dequeue all update curr correctly, so on the normal reschedule path only the microseconds between those and the pick are missing, and I could not measure a latency difference there. Three paths have nothing before them on that rq though: - pick_task() on the sibling rqs of a core under core scheduling (kernel/sched/core.c), which updates that rq's clock first for exactly this reason - fair_server_pick_task() - yield_task_fair(), where the stale value feeds the entity_eligible() test that guards forfeiting the remaining vruntime There curr can be a full tick behind, as it was before that commit. No new behaviour for the entity being updated: without cgroups ->h_curr is already the task, so these two call sites already run the full update_curr() including update_deadline(), dl_server_update() and the resched_curr_lazy() at the end. This makes the cgroup case do the same. Fixes: 85570f10a4c6 ("sched/eevdf: Move to a single runqueue") Signed-off-by: Zhan Xusheng Reviewed-by: Vincent Guittot --- kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 001140132a7d..3ea9bb5c3b47 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10052,7 +10052,7 @@ struct task_struct *pick_task_fair(struct rq *rq, s= truct rq_flags *rf) =20 /* Might not have done put_prev_entity() */ if (cfs_rq->curr && cfs_rq->curr->on_rq) - update_curr(cfs_rq); + update_curr_eevdf(cfs_rq); =20 se =3D pick_next_entity(rq, true); if (!se) @@ -10155,7 +10155,7 @@ static void yield_task_fair(struct rq *rq) /* * Update run-time statistics of the 'current'. */ - update_curr(cfs_rq); + update_curr_eevdf(cfs_rq); /* * Tell update_rq_clock() that we've just updated, * so we don't do microscopic update in schedule() --=20 2.43.0