From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (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 F12ED136358 for ; Sat, 6 Dec 2025 01:20:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764984060; cv=none; b=GknfY1ZwyHAuT5F1znJKto+Oe2p/5MNNLoGdCDi/pjGpsOyvQ+FaBEYs2dPxfvkRMiolXf8QJtN3eI82xFZjqasD8NrB7p9Lq5YoAmi+YypOgVm0DgSIDlJtiuv79i2PeZOItlLL1bSgo3gt13oK4OZFUz0RIj1fZlLBHkcQ3Dg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764984060; c=relaxed/simple; bh=HyHvweBHz+GGYXZQnQmFoOfJNVerIow9c6WfPLus+s0=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=STf+zL11ICJDMBjLJofqnOP5Y+ZhZ5ea6ISXdOK9fHzNy+3H6yhwJAbNItYxPU7uVS1i2O5NAx3JxAoMRnp5gkKwZ3h9UsnaJCUiYBJLZxIJLNSA427amea1Lqyf4P3YUTMuQygiSEqRJF+vKYMAZ/QF0dVGkPRlrT+3F3JLhsQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Powk+C0z; arc=none smtp.client-ip=209.85.218.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Powk+C0z" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-b7277324054so378823466b.0 for ; Fri, 05 Dec 2025 17:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1764984057; x=1765588857; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=i9mMKajSjRc1Sw1Uv8TF05BmHwOLSll6NY1MAiawFUQ=; b=Powk+C0zwipuFNuRAo7dGf+dgOF/XNvLrfV0luJiKusJk3488DZl5V61cb4lSV2/Z9 rGRxFEGkkUpxih1QxffuTiu400AkvNYTBNy5psl3MKY45G3R6DZcSiHkcg2mdnFOJ2r7 cngeiK9mJMr+2H7aYDs6m8SEkMabQ6bbGXXyIlLR3WH9k6mbCX9eydY/C+Dg91u+UVPm VeNnozIjO/8Ku8olDbA9I3Kp2U+Ssh3c4NHZIuJCidAuhzvtkE7e62VDH5ogc//VNpeH UBmj04z5xLGNU67BFSe0f77HpASEzbuMDFWI6jnSaTt6iIW60cvElV7ll17WE39hwJDJ YOUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764984057; x=1765588857; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=i9mMKajSjRc1Sw1Uv8TF05BmHwOLSll6NY1MAiawFUQ=; b=G1q0Q8VQL03nK6ul/SFr4f4XAJshCMaCBZdcbflLFN6pTC7eGoLTAW0190gCADSkVn lZ+h1ZClLezldLqrckUs8NulczKaK0u1p4mAcAliVzF1A6LsFQrOBgrsbLXisQBt3sNG OGTOHOb8aVQmFH/96qhTQ0fTDvX0IUxv6qKA85CpiDe5+ImKxZWQn+qkFsfoeNsBTRiu 1L53WAWqyQDWrBWuNm+8eny0BlE3dMsax0CrDvWLojUbFFUtmGD/H0Ma/f+/RNupAfTy VCAxCsV8kogrhvvVTCXe33S8EKkn3SZUK3hcTOeLKiERcT3a+dXZgVe0SnWIfklFtrQP BNrw== X-Forwarded-Encrypted: i=1; AJvYcCW9arRf9lVmkDzTXGv1YM5FNACNdCNexzYAuIOQj/JN6l/bgrxLdv2la4pP/tQ4ypMxIiuN9K2Rb7DvxqQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyiR2B5t+CbvAfti4hM3KuZfpOYzfr028Sn6IUj4CzxitO7WY+v 0cgyQmQu3Cqtk5VSBHkbLc1+iduI6Mgaz7k28StAhOxJafiO4pA5JvcX1RvHPb7UdkTMgQnuVLz FaHeYwX0AhqpGo4Lma/s5C9BQ3oFoBhzvsVyBb/dF X-Gm-Gg: ASbGnctdAtZ8RSbvadm+pGnMxpS0i+uMuwfiyI7cdkrZ1sMdowWKYqH5ZYQ2TVVA5lu 2hm/pjsS6GBBIRiyFwag0N+YIfDWkgPxOB7PyNCyncGIfbyaK6QADZjRLNDoMcn/GmOUbuRqexk WflsamPJDnIx7fa2Y8c519yp1w6VuKOtzR83M2TsvSNq6yby1taLGTujygXlskieN91DV1NLIRy ZRV0tLiqNFt+zTNtrdOfGGiuZC403ZZlkUTucWlphgsgS0pnURERNikrocuXgR1FOz2AqqGc9Ps JGI4qsN+h9KSAvji/uy+23VJ4vpA6Q== X-Google-Smtp-Source: AGHT+IGR8F1iEpZZW6qBTwF6hFcwBFm0DCBb7QanMFvI56aZJxxmyQWbwNaN1+bhxX9iJugnmG8O0maLvIHYo2YFoZ8= X-Received: by 2002:a17:906:7311:b0:b79:c460:39a4 with SMTP id a640c23a62f3a-b7a24781673mr103180366b.56.1764984057017; Fri, 05 Dec 2025 17:20:57 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251008131214.3759798-1-vincent.guittot@linaro.org> In-Reply-To: From: Samuel Wu Date: Fri, 5 Dec 2025 17:20:45 -0800 X-Gm-Features: AQt7F2pEnHN3CagMKl4MOu6qtUkJr2frmZHPejpr7bPJnbkqlPDx97A946qYf4E Message-ID: Subject: Re: [PATCH] sched/fair: Fix pelt lost idle time detection To: Vincent Guittot Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, Android Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 5, 2025 at 4:54=E2=80=AFPM Samuel Wu wrot= e: > > On Fri, Dec 5, 2025 at 7:08=E2=80=AFAM Vincent Guittot > wrote: > > > > On Tue, 2 Dec 2025 at 01:24, Samuel Wu wrote: > > > > > > On Wed, Oct 8, 2025 at 6:12=E2=80=AFAM Vincent Guittot > > > wrote: > > > > > > > > The check for some lost idle pelt time should be always done when > > > > pick_next_task_fair() fails to pick a task and not only when we cal= l it > > > > from the fair fast-path. > > > > > > > > The case happens when the last running task on rq is a RT or DL tas= k. When > > > > the latter goes to sleep and the /Sum of util_sum of the rq is at t= he max > > > > value, we don't account the lost of idle time whereas we should. > > > > > > > > Fixes: 67692435c411 ("sched: Rework pick_next_task() slow-path") > > > > Signed-off-by: Vincent Guittot > > > > --- > > > > > > > > I Noticed this while reviewing [1] > > > > > > > > [1] https://lore.kernel.org/all/20251006105453.648473106@infradead.= org/ > > > > > > > > kernel/sched/fair.c | 26 +++++++++++++------------- > > > > 1 file changed, 13 insertions(+), 13 deletions(-) > > > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > > index b3be1e2749ce..dd0ea01af730 100644 > > > > --- a/kernel/sched/fair.c > > > > +++ b/kernel/sched/fair.c > > > > @@ -8920,21 +8920,21 @@ pick_next_task_fair(struct rq *rq, struct t= ask_struct *prev, struct rq_flags *rf > > > > return p; > > > > > > > > idle: > > > > - if (!rf) > > > > - return NULL; > > > > - > > > > - new_tasks =3D sched_balance_newidle(rq, rf); > > > > + if (rf) { > > > > + new_tasks =3D sched_balance_newidle(rq, rf); > > > > > > > > - /* > > > > - * Because sched_balance_newidle() releases (and re-acquire= s) rq->lock, it is > > > > - * possible for any higher priority task to appear. In that= case we > > > > - * must re-start the pick_next_entity() loop. > > > > - */ > > > > - if (new_tasks < 0) > > > > - return RETRY_TASK; > > > > + /* > > > > + * Because sched_balance_newidle() releases (and re= -acquires) > > > > + * rq->lock, it is possible for any higher priority= task to > > > > + * appear. In that case we must re-start the pick_n= ext_entity() > > > > + * loop. > > > > + */ > > > > + if (new_tasks < 0) > > > > + return RETRY_TASK; > > > > > > > > - if (new_tasks > 0) > > > > - goto again; > > > > + if (new_tasks > 0) > > > > + goto again; > > > > + } > > > > > > > > /* > > > > * rq is about to be idle, check if we need to update the > > > > -- > > > > 2.43.0 > > > > > > > > > > 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 p= atch | > > > +-----------------------------------+-------------+------------------= --+ > > > | 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). - with patch: https://ui.perfetto.dev/#!/?s=3D964594d07a5a5ba51a159ba6c90bb= 7ab48e09326 - without patch: https://ui.perfetto.dev/#!/?s=3D6ff6854c87ea187e4ca488acd2e6501b90ec9f6f