From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 56244334C2D for ; Fri, 16 Jan 2026 14:21:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768573302; cv=none; b=MO/EGafHcF1n0MiFQE4Kcvt8vd34l2QxTtXDESqtIHcK9npaeI/gr8A3cs1gD9ycgnCmzlMnLVOYBJDLDzST1YigoPHsLaed595xOvlLfuEy/f98Nj3/vwJY7xlHS3uzWlZRM90WjWjpotqxb8HouZ/5tpQ0S2zDIMv6H5ipxts= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768573302; c=relaxed/simple; bh=A8qKwYyIb+eioaGRM1ox9Mry43CCOZxDjKG3Fld2ljs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Juv+Xbg3vXGlWWIyj6UJj+XMdJbvtIlwltsiIDWdeh6gqn5kRiIad001yS2/pa4QiUykikxmhtrO8b2GFoE7iPC+EhfZZaZkfZqDA3dCR+WxWERtsxo0aiQ2TDKcwrbCSztwed+n0Z2LExvMkH1Gqt4SARXf9rZIcSRKKvRnVTw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=qOccZ82L; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="qOccZ82L" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so13209825e9.3 for ; Fri, 16 Jan 2026 06:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1768573298; x=1769178098; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=SUi/tHVBd8ryQwlql51cahMGqfhrG1tYRsflCFi2ol8=; b=qOccZ82LYmG4vMfpbrLpliCQZltd75KnCyw5UkQoE51ftGdjQ7THYrenGKnPsJL9hN GKFW+u1lmHyWiFXaym+HDfxxahOe7b1XppD9PMggeXOVqsN8ksiDA3EJJFna2F5di/qz hR12L457OF1++Ynfoqw6zSio7BE1OJFq/NiJK+6/Bu2UkLbPMGsgK/7DSD7YIkepyw7T mVff/86Qs8XreTAcUvUp6UhewqV95FWwW3exOlwzQMQSM0USJCHiYuHlsKjCPH9N/gPt x2gTv21Tj+HvDkec2eK/CvkDA8EfzRciI7Y/NpUxyxsqlYobskPnm/XzjI3//dNrbcPK jC+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768573298; x=1769178098; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SUi/tHVBd8ryQwlql51cahMGqfhrG1tYRsflCFi2ol8=; b=RLtyr/+CV8Z/oeO9/kziBqvPwpk3nn4a72/zDaeCq08rje90JkmK+FYZ1KXureipQA +LH+0uStpZNS4fsKdLYLU6g8NpYTpuU5MBihW4lt6uTdAk7z4CPjOIb0fi2L6BZJF7c2 sLvIFWdmTHTw59eRxvv+tb1IlU2+USNjaoCoGyHCgKUvb9GGGztb+xaG3pOWAzkEog/a NtoSqhwUb4oSmCnQdcLHY5+M4Cv7s1g6umKij5sk7tXthBs3U/BYsSkURm0saIBXBTnH frfFrHw/EsW2qLrpYCVUi/8ZZlqXA1X8tqPjh7WQwj5oBAgS12gv4aFekp4ysXTqOmk1 B8EA== X-Forwarded-Encrypted: i=1; AJvYcCX3d5KZqzWRwHPvBGaNCPTNGndtIpKR+2vegSqzN+kH21IDzCEhqLeaMBlmmGofu39/e9+yjYNdTVHLyuY=@vger.kernel.org X-Gm-Message-State: AOJu0YxQlRO9Kv5es7+T3YIGcHrFE8XAqqJBQPzEGY3FaFd/8g4dwJtK sUZw8CnBmhffR75lSLMBbscFKfv7gMDXfJQlaotAsf04G+ZSacyqzb8BWnzniXZD2eA6owlJNqJ UB70+ X-Gm-Gg: AY/fxX4J4bEIzN6TsJ1ec8wN4iPWiaFCF78DCDbZ9MRz3CJKr9FMAiGtxK82N7k8V/W 0mpf8npZHOnpGWq35dFXbeBU5oV/J9y3VxvRuuEl8m1Ckfr/mya1S3KLmRyoWHHYboeZCAGyEFR cxNbnHPO/bESN3qYXetg9Z1khEObCe68S5hDWrJ4eveWSW5+PehoFZbok0Yo8kKSMXaufQZ+YR4 6lQe0GByzDot+lrv3ZDGufoapL0+IF2Di/EaT87yBEYzozGz5NodPihqEhQr+VpX8ccF5oTpft2 wmE4YVdP9+FE4ZUa0/0rxAE658HVP3B6SbYuY5uxxOs6Gg0a1D8yKwpK/dn1YZi7bpqos+0bZKB sYmJxUkXVWBvEjFR6c3CnDiJq761pxlS8OA8ku4aKaMqPrpbCVOZ0hjEDs06diJIpJyOBT8pxFs aY4itC/Qd/KQgDXqzC X-Received: by 2002:a05:600c:c04b:10b0:477:582e:7a81 with SMTP id 5b1f17b1804b1-4801eab9e81mr27068045e9.4.1768573297864; Fri, 16 Jan 2026 06:21:37 -0800 (PST) Received: from vingu-cube ([2a01:e0a:f:6020:1b29:23a9:fb39:a3cd]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e8d90b3sm45974575e9.15.2026.01.16.06.21.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 06:21:37 -0800 (PST) Date: Fri, 16 Jan 2026 15:21:35 +0100 From: Vincent Guittot To: Alex Hoh =?utf-8?B?KOizgOaMr+WdpCk=?= Cc: "wusamuel@google.com" , "bsegall@google.com" , "vschneid@redhat.com" , "dietmar.eggemann@arm.com" , "peterz@infradead.org" , "rostedt@goodmis.org" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "mgorman@suse.de" , "juri.lelli@redhat.com" , "kernel-team@android.com" Subject: Re: [PATCH] sched/fair: Fix pelt lost idle time detection Message-ID: References: <20251008131214.3759798-1-vincent.guittot@linaro.org> <8cf19bf0e0054dcfed70e9935029201694f1bb5a.camel@mediatek.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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8cf19bf0e0054dcfed70e9935029201694f1bb5a.camel@mediatek.com> Hi Alex, Le vendredi 16 janv. 2026 à 06:51:03 (+0000), Alex Hoh (賀振坤) a écrit : > On Sat, 2025-12-13 at 04:54 +0100, Vincent Guittot wrote: > > Hi Samuel, > > > > > > On Sat, 6 Dec 2025 at 02:20, Samuel Wu wrote: > > > > > > On Fri, Dec 5, 2025 at 4:54 PM Samuel Wu > > > wrote: > > > > > > > > On Fri, Dec 5, 2025 at 7:08 AM Vincent Guittot > > > > wrote: > > > > > > > > > > On Tue, 2 Dec 2025 at 01:24, Samuel Wu > > > > > wrote: > > > > > > > > > > > > On Wed, Oct 8, 2025 at 6:12 AM Vincent Guittot > > > > > > wrote: > > > > [...] > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I am seeing a power regression I've observed with this patch. > > > > > > This > > > > > > > > > > The problem is that this patch is about fixing a wrong load > > > > > tracking > > > > > which can be underestimated on systems that become loaded. > > > > > > > > > > > > > I feel the patch is doing the proper thing, which is the > > > > appropriate > > > > bookkeeping when idle is the next task. I just wasn't 100% sure > > > > if > > > > there were some other indirect impact that was unintentional, so > > > > thought it would be good to send a report out and have another > > > > set of > > > > eyes look over it. > > > > > > > > > > test was performed on Pixel 6 running android-mainline > > > > > > (6.18.0-rc7 > > > > > > based); all scheduling vendor hooks are disabled, and I'm not > > > > > > seeing > > > > > > any obvious sched code differences compared to the vanilla > > > > > > upstream > > > > > > kernel. I am still actively working to see if I can find a > > > > > > simpler > > > > > > sequence to reproduce this on mainline Linux. > > > > > > > > > > > > The Wattson tool is reporting an increased average power > > > > > > (~30-40%) > > > > > > with the patch vs baseline (patch reverted). This regression > > > > > > > > > > For a use case in particular ? > > > > > > > > This was for BouncyBall apk, which is a bouncing ball animation. > > > > I'm > > > > still trying to find a method to reproduce this on Linux, but > > > > still > > > > haven't been able to. Also we've been checking internally to root > > > > cause this, but nothing definitive yet. > > > > > > > > > > > > > > > correlates with two other metrics: > > > > > > 1. Increased residency at higher CPU frequencies > > > > > > 2. A significant increase in sugov invocations (at least 10x) > > > > > > > > > > > > Data in the tables below are collected from a 10s run of a > > > > > > bouncing > > > > > > ball animation, with and without the patch. > > > > > > +-----------------------------------+--------------+--------- > > > > > > ----------+ > > > > > > >                                           | with patch |  > > > > > > > without patch | > > > > > > +-----------------------------------+-------------+---------- > > > > > > ----------+ > > > > > > > sugov invocation rate (Hz) |       133.5 > > > > > > > |                   3.7 | > > > > > > +-----------------------------------+-------------+---------- > > > > > > ----------+ > > > > > > > > > > > > +--------------+----------------------+---------------------- > > > > > > + > > > > > > >                   |         with patch: |    without patch: > > > > > > > | > > > > > > > Freq (kHz) | time spent (ms) |  time spent (ms) | > > > > > > +--------------+----------------------+---------------------- > > > > > > + > > > > > > >     738000 |                   4869 |                  9869 > > > > > > > | > > > > > > >   1803000 |                   2936 |                      > > > > > > > 68 | > > > > > > >   1598000 |                   1072 |                        > > > > > > > 0 | > > > > > > >   1704000 |                     674 > > > > > > > |                        0 | > > > > > > >              ... |                        ... > > > > > > > |                       ... | > > > > > > +--------------+----------------------+---------------------+ > > > > > > > > > > > > Thanks! > > > > > > Sam > > > > > > For completeness, here are some Perfetto traces that show threads > > > running, CPU frequency, and PELT related stats. I've pinned the > > > util_avg track for a CPU on the little cluster, as the util_avg > > > metric > > > shows an obvious increase (~66 vs ~3 for with patch and without > > > patch > > > respectively). > > > > I was focusing on the update of rq->lost_idle_time but It can't be > > related because the CPUs are often idle in your trace. But it also > > updates the rq->clock_idle and rq->clock_pelt_idle which are used to > > sync cfs task util_avg at wakeup when it is about to migrate and prev > > cpu is idle. > > > > before the patch we could have old clock_pelt_idle and clock_idle > > that > > were used to decay the util_avg of cfs task before migrating them > > which would ends up with decaying too much util_avg > > > > But I noticed that you put the util_avg_rt which doesn't use the 2 > > fields above in mainline. Does android kernel make some changes for > > rt > > util_avg tracking ? > > > I believe this change can indeed account for the observed increase in > RT util. > > When prev is the last RT task on the rq, the scheduler proceeds through > the CFS pick-next flow. With this patch, that path advances > rq_clock_pelt to the current time. However, updating rq_clock_pelt at > this stage does not seem correct, as RT util has not yet been updated. You're right, put prev happens after we updated pelt clock Samuel, Could you try the fix below ? --- kernel/sched/fair.c | 6 ------ kernel/sched/idle.c | 3 +++ 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 108213e94158..bea71564d3da 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8989,12 +8989,6 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf goto again; } - /* - * rq is about to be idle, check if we need to update the - * lost_idle_time of clock_pelt - */ - update_idle_rq_clock_pelt(rq); - return NULL; } diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index 65eb8f8c1a5d..91af6acafe44 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -260,6 +260,9 @@ static void do_idle(void) { int cpu = smp_processor_id(); + /* Sync pelt clock with rq's one */ + update_idle_rq_clock_pelt(cpu_rq(cpu)); + /* * Check if we need to update blocked load */ -- 2.43.0 > > The RT util update actually occurs later in put_prev_set_next_task(), > and it relies on the original value of rq_clock_pelt as input. Since > rq_clock_pelt has already been overwritten by the time the RT util > update takes place, the original timestamp is lost. > > As a result, the intended CPU/frequency capacity scaling behavior is > disrupted, causing RT util to increase more rapidly than expected. This > appears to be an unintended consequence introduced by the patch. > > > > > > > > > - with patch: > > > https://ui.perfetto.dev/#!/?s=964594d07a5a5ba51a159ba6c90bb7ab48e09326 > > > - without patch: > > > https://ui.perfetto.dev/#!/?s=6ff6854c87ea187e4ca488acd2e6501b90ec9f6f