From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 4418219AD5C for ; Thu, 23 Apr 2026 02:35:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776911731; cv=none; b=HQ4HAAw+5bCAm/64hNuh5gYKaLFHrX9QrcfNSTjbELfdc+GrAfXKvv4qgGk2V0QsniByVcv3nnYSvC6xcjuFXxJLF94IKa22o3jLsnvHrz+Piq1Ejn5eDJP/yWpes6Bj85Uu2YJKVUVReZbVIWbK3/SnLsBDoVQV+u700F6Jo4w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776911731; c=relaxed/simple; bh=C1J7FFjlKyUMLzqExxuqT0DV4Rimw6H4xMX60Ve4tlw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=IX26nmMTqyIi3Ygh3DI8qFrgz6jcxYoiBPp87objuIRCGX+JnKoWEmlqphaxLP+8z88yDnqwCqDNLEP4vHXPbHvVsA1wEDbQOubBhgLcABN+B27u9lHy4TA5iVXKw1sXs1J6yyEUSvneRzH17o/reb7IUo/yUKdj6JvdUgSwEEw= 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=c5BwidO4; arc=none smtp.client-ip=209.85.214.182 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="c5BwidO4" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2ab46931cf1so49823625ad.0 for ; Wed, 22 Apr 2026 19:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776911730; x=1777516530; 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=gA/9MGsY0C55TmEgi3GftiRLudxmgpVySLXgAhfq27w=; b=c5BwidO43M8WLth+RTkd7KXY7dtgnDWWCbxuPc1ChU/t2GRPNYf5VeNgZhIKNCmhvY OSk4CJQM67ZnlS99WjpdO0wHrUNn5nQYGpHFlJezEQaJ+Hg3RMQeHTY3c61TtoIozt1A WoWZlMfcJ3rGSqcDe1uuJ9n+UGGCZZwJIP3oQmJiLovf8M8bQ+cSbXEQ1FBxB0F8FP7k 3wFFP6RemAfvcWTD1+x/GLa/o8vxqtlc5g24DEWSjXj5o+KUtF68DTtKL4CXRcxNaoS4 RXs8UPh0M5/E/ChMdwg/ZF7No+gOGAFZqHgHfVoMwlFpyZsvgrcssFRUy2OSnaR9k2Je GGPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776911730; x=1777516530; 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=gA/9MGsY0C55TmEgi3GftiRLudxmgpVySLXgAhfq27w=; b=F9r2jZp7xd9MWnWGh9Ljx0F4IyWJKYJ7CXZFVfBAzGXBEE0PDnE3BGJLP8m5usOSAk GbmIwhd4gl+PMlj9wDQJDyrsh0oxaNicIr2dpT5xyUarbpIFXHPlFkdO/tneFbp7mE2X stdekqeXQQbxE93V9e9tC+oVKXSJAz1Eel4JviQOCZXFODEAjQXNLirLmy5ALU/P3eIt PPr9zqTwESWWjnlH1VQl0JOXQ8r1HYmtuOX3iI9pPpdW69y6mixeWH3Tj+maQJ5r74WX YZXoZYhpDyn1qO5SOkl/ob0Ap8CmlofCasNFs/ZktRlKCz+2eF/tQtS6voQZypc+JOXr Hqew== X-Forwarded-Encrypted: i=1; AFNElJ+0YbZ9t4cqme4UY4WJOjYNd7mdikd3MU+BBM8JyQEO8fNRrnAMV6YxIDU9YFkZnbvUmEtwwQYMjevDzi0=@vger.kernel.org X-Gm-Message-State: AOJu0YwONJfVPxDHbPH8X/jK7M5XLFERCl44uenW8IPOnrCQRURdzZ5P xvoly3JP42+CYUGRqhnuX8GPpEf8DrZnbFxXZYp1iVflyxEXYtTtjfTm X-Gm-Gg: AeBDieuUwVGeT2HBANJTUITZ5TB2pqfSoD+VagbDMQhPHotLT2DQOi2dIch+T1JNwQU DIo0rX4oR5mEbKQRJEAfV9TxuQG0iPwe8buIKxPI6tap3ih02ZWMDggHPfSOkzRDsrTs6iB5Am4 fOEh3LPAHlk1pgTORjarirgfkU0/AlYskFweqEWjKiPuorvMWxkRM6lc9vVIWuM2dIF9F7mooAd 3NefAhufBDWF9RZlv1fF7vE/W68XEtcL4V8MJWAl8bJxmD4se9jhaLgl53601FBtqTqKuC6RTnB 107nR6SM5GQHLiXcylEsR2SjH/fdapAO9F0fk2a6vknuba3jcxwqK5VoY6/0xyEjqbYGuCnKW4H F7r1PMXgEUHpkzeaair6pmu3H9Td8mxYxL442XVkBYQrK2TMoMusmt1jMJdyvU9DH5E6CBrTqP/ g3BnOu5Ln48WQfL6rHt7ECu2wn+ueritLu6YtU2dFJzXFhIBZpEiEuE2QKX0yDNAs0ZabYHj/Pl lOcBaZ10iplHiYKPNUgr2xkmRq7M1WBJMVRONsGjVI= X-Received: by 2002:a17:903:2acb:b0:2ae:5ab4:f4c0 with SMTP id d9443c01a7336-2b5f9e5e962mr224985755ad.13.1776911729524; Wed, 22 Apr 2026 19:35:29 -0700 (PDT) Received: from GTR.flets-east.jp.iptvf.jp ([2400:4052:8024:9500:45a8:7ff0:3f28:33e2]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b5fab4bf7bsm178327555ad.81.2026.04.22.19.35.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 19:35:29 -0700 (PDT) From: Masahito S To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, dnaim@cachyos.org, christian.loehle@arm.com, Masahito S Subject: [PATCH v2] sched/idle: Fix avg_idle saturation by establishing symmetric idle entry hook Date: Thu, 23 Apr 2026 11:33:22 +0900 Message-Id: <20260423023322.1293923-1-firelzrd@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260417020654.911709-1-firelzrd@gmail.com> References: <20260417020654.911709-1-firelzrd@gmail.com> 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 Content-Transfer-Encoding: 8bit update_rq_avg_idle(), called from put_prev_task_idle(), computes rq->avg_idle as rq_clock() - rq->idle_stamp. However, idle_stamp is only set by sched_balance_newidle() when a CPU enters CPU_NEWLY_IDLE through the fair class path. When the idle task is preempted without sched_balance_newidle() having run (boot, hotplug, sched class transitions), idle_stamp remains 0, producing a delta equal to rq_clock() — a value in the billions of nanoseconds — which saturates avg_idle at 2 * max_idle_balance_cost. This inflated avg_idle prevents sched_balance_newidle() from early-returning (fair.c: avg_idle < max_newidle_lb_cost check), making it overly aggressive. The resulting excess newidle migrations override wake-time placement decisions made by select_idle_sibling(), degrading cache locality that careful placement (recent_used_cpu, select_idle_core, etc.) is designed to preserve. Fix this by: 1. Adding an idle_stamp validity guard to update_rq_avg_idle(), so that a zero idle_stamp is never used as a timestamp. 2. Setting idle_stamp in set_next_task_idle() when it has not already been set by sched_balance_newidle(). This establishes a symmetric idle entry/exit contract: set_next_task_idle() marks the start of the idle period, put_prev_task_idle() measures and records it via update_rq_avg_idle(). The entry hook preserves idle_stamp if sched_balance_newidle() has already set it, maintaining the existing semantic where balance-attempt duration is included in the idle measurement. Signed-off-by: Masahito Suzuki --- Changes in v2: - Added missing Signed-off-by tag (no functional changes). Thanks to Eric Naim and Christian Loehle for pointing this out. kernel/sched/core.c | 3 +++ kernel/sched/idle.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 496dff740d..ec801f731c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3633,6 +3633,9 @@ static inline void ttwu_do_wakeup(struct task_struct *p) void update_rq_avg_idle(struct rq *rq) { + if (!rq->idle_stamp) + return; + u64 delta = rq_clock(rq) - rq->idle_stamp; u64 max = 2*rq->max_idle_balance_cost; diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index a83be0c834..9ceb7e6224 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -491,6 +491,9 @@ static void set_next_task_idle(struct rq *rq, struct task_struct *next, bool fir schedstat_inc(rq->sched_goidle); next->se.exec_start = rq_clock_task(rq); + if (!rq->idle_stamp) + rq->idle_stamp = rq_clock(rq); + /* * rq is about to be idle, check if we need to update the * lost_idle_time of clock_pelt -- 2.34.1