From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 06FE626E6F5 for ; Thu, 23 Oct 2025 16:03:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761235382; cv=none; b=Bd008PmYjTxoZEkhftNJbpAbPTQv/eJcPCIPwNbCul8wn9RqnmDnI7EomF/0Wcr8ZjAsBJkWHujUVa1sUZFgldsVsZkQs+7yHIA7xVE6bSnC+aOIQQTkDZGQ5uQQ31AEoPTY4SZFkEv2uIC86/5j+7EQn0o+gU+o+zCQmTsXVC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761235382; c=relaxed/simple; bh=0T40hKL26YolCQLnSKyrMR+Bn6Jtsl61c5TdM8zx1cU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=bhp4zFHL3bplN9FugUR10vqBYnFyPcZOMhmNFcB8xYY7GP+1XpgphzNYkQou2IpvxCxfKnLElGDUh9T3sgqVOmEuFdfrtz9xc9cUyCR8pCtlWc/wjG691QUUEF7xJVo/7jcE6I2BaBCcJ8ypUDawGfu0AiTPNrbPi33A5aNay54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=telus.net; spf=pass smtp.mailfrom=telus.net; dkim=pass (2048-bit key) header.d=telus.net header.i=@telus.net header.b=h5gBVAcR; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=telus.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=telus.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=telus.net header.i=@telus.net header.b="h5gBVAcR" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-7a27bf4fbcbso659459b3a.1 for ; Thu, 23 Oct 2025 09:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=google; t=1761235380; x=1761840180; darn=vger.kernel.org; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=JH/e1IwTn9e6m+oKiv8OxIW1/g/8aOTw78lb+wUnrjs=; b=h5gBVAcRfECI+2e7VzYBsITH7sOL8JUDpVx5uOgTdnG40wXbEblSR8v6v9ICxTCX6r hucMxHUrcjaCV9oXVdEZUVC/tbglXsBY/F6aTnAE9XWijToJMXAsf1Yq/v98JCFMWy7w Apgwa6jn1Kio5JiX9aVYrFhaMGRcOUMt1wLrl7w9deQqQJ6jagpGU9cqxiDDWztsJf+L 8bsHdLYiSQqEs+0qDUUC4sLPjfHUm+o9We3iZyI3KV2sestiIFwz7ZAIyT/d8sFtANfk SjwXWNjy3Zjt90vCqO4+/K2Fl0KVvNuryxFQ6hRstLQL4etUVKc2Ns1KUZkOgJgTBQT+ J0CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761235380; x=1761840180; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JH/e1IwTn9e6m+oKiv8OxIW1/g/8aOTw78lb+wUnrjs=; b=OgeH4jwaUZ0bfEk83U8pkG21FgeI7yJ3IRoV/b7nVsPLk9tISDDZPI2RbaUzuHIfvq DEbpus+XM6YtCsDi2UNKB9NbEVBp8xMpHeW7XgGBBietGykvSKNn6ZCcwp85agsyn89S YZkNE7mdbnHFAxc0Fhy+0/pEhyjBctLehPCj8FLaGLb6BoGxSMvqzwXw9/VoBY7RpAeC 0uxOParVIr79bop49tWODPl9Q53twf5qlWtfPUgXqoNc7uIfvfr8CGoNVPV+j+KE4VLR N7w+3fDefRs9RO+amoFzWFXTs/2pAqiTSeGZ7Ab6YAfhuxiG5gu8K0H28afwC5bxFYgG E0GA== X-Forwarded-Encrypted: i=1; AJvYcCXttheqgeKdxHKxJtvwCW4BeK7+eeOJtfxB2+PBXXbTBW4bug2PSDtkVirj+zZ0OUGN60Gudjys3cSqw/0=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5daKsFigwuhYWAB7ii0eWZT1lLCdu616VOJa2+2HGeREoxIGk 98akJKcs0FxgESU300zB7XRN5yaaQZCBkFIx2QZtHG1ktrjrFV/PWXToO36D/XZ+Xn8= X-Gm-Gg: ASbGncusxE85ORXiHkp/3o4wSelkjmYhVPNjaZIQQ6Lptq3xYPEaCOOAyCkJXoabj0j kvpWlN56NPw2LDNCKcMqiOzBX6IjlZBJa5dU2zenG1ARV3HBayvUICwtL9iaewAg8I53LaSuLAp y0SXu+Vz/0XkqX3jAmGIECcrnPSPtZb+GuNqOPiGX2Mh34RSoEgMaprxMFfUwVZAH8atEXL+WKe n0ANQlbNmR3L58q2BoO7UDY84fyexJ+nKPQdx4qwXmIgoewoWip1ac2Y6J0Kce0+Nrm3gm0dX8x Tq315SbFqGWtSPjLXxmJUzzxk+3EH6ej5tjSDCAIweOOOIGk6NQWIzh6mfrKbvCStpdfubFld10 wCPDXFMAox+vo4MXhe1kEdfCkDq5qYY9Fn2B3lS5TjkLaF3NWgz0diRZglP1/I9M5klr8aQlCnT D82nbr6aJoXsLeVVdzYc9Wa/VoFQk0l/PvRmOj+Y2PKw8+ X-Google-Smtp-Source: AGHT+IHa6CnmrO8xJXDnGny1Z43wB3uTWDalpzMKHlkKpTQZZnEYpOXUYPsP9QurSz3gT7q6oOes7g== X-Received: by 2002:a05:6a00:93d7:b0:7a2:6db4:4c81 with SMTP id d2e1a72fcca58-7a26db44de0mr4051337b3a.3.1761235378739; Thu, 23 Oct 2025 09:02:58 -0700 (PDT) Received: from DougS18 (s66-183-142-209.bc.hsia.telus.net. [66.183.142.209]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7a274a9cec5sm2992577b3a.20.2025.10.23.09.02.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Oct 2025 09:02:58 -0700 (PDT) From: "Doug Smythies" To: "'Rafael J. Wysocki'" Cc: "'Frederic Weisbecker'" , "'LKML'" , "'Peter Zijlstra'" , "'Christian Loehle'" , "'Linux PM'" , "Doug Smythies" References: <2804546.mvXUDI8C0e@rafael.j.wysocki> <5043159.31r3eYUQgx@rafael.j.wysocki> <004501dc43c9$ec8aa930$c59ffb90$@telus.net> <5040239.GXAFRqVoOG@rafael.j.wysocki> In-Reply-To: <5040239.GXAFRqVoOG@rafael.j.wysocki> Subject: RE: [PATCH v1 1/3] cpuidle: governors: menu: Avoid selecting states with too much latency Date: Thu, 23 Oct 2025 09:02:57 -0700 Message-ID: <001a01dc4436$80b80aa0$82281fe0$@telus.net> 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: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQFe4hIXA7yjTyFTeu7yKR6UgyMZTANsg+YRAdzC7nACxm/pQLWKKQyg On 2025.10.23 07:51 Rafael wrote: > Hi Doug, > > On Thursday, October 23, 2025 5:05:44 AM CEST Doug Smythies wrote: >> Hi Rafael, >> >> Recent email communications about other patches had me >> looking at this one again. >> >> On 2025.08.13 03:26 Rafael wrote: >>> From: Rafael J. Wysocki >>> >> ... snip... >> >>> However, after the above change, latency_req cannot take the predicted_ns >>> value any more, which takes place after commit 38f83090f515 ("cpuidle: >>> menu: Remove iowait influence"), because it may cause a polling state >>> to be returned prematurely. >>> >>> In the context of the previous example say that predicted_ns is 3000 and >>> the PM QoS latency limit is still 20 us. Additionally, say that idle >>> state 0 is a polling one. Moving the exit_latency_ns check before the >>> target_residency_ns one causes the loop to terminate in the second >>> iteration, before the target_residency_ns check, so idle state 0 will be >>> returned even though previously state 1 would be returned if there were >>> no imminent timers. >>> >>> For this reason, remove the assignment of the predicted_ns value to >>> latency_req from the code. >> >> Which is okay for timer-based workflow, >> but what about non-timer based, or interrupt driven, workflow? >> >> Under conditions where idle state 0, or Polling, would be used a lot, >> I am observing about a 11 % throughput regression with this patch >> And idle state 0, polling, usage going from 20% to 0%. >> >> From my testing of kernels 6.17-rc1, rc2,rc3 in August and September >> and again now. I missed this in August/September: >> >> 779b1a1cb13a cpuidle: governors: menu: Avoid selecting states with too much latency - v6.17-rc3 >> fa3fa55de0d6 cpuidle: governors: menu: Avoid using invalid recent intervals data - v6.17-rc2 >> baseline reference: v6.17-rc1 >> >> teo was included also. As far as I can recall its response has always been similar to rc3. At least, recently. >> >> Three graphs are attached: >> Sampling data once per 20 seconds, the test is started after the first idle sample, >> and at least one sample is taken after the system returns to idle after the test. >> The faster the test runs the better. >> >> Test computer: >> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz >> Distro: Ubuntu 24.04.3, server, no desktop GUI. >> CPU frequency scaling driver: intel_pstate >> HWP: disabled. >> CPU frequency scaling governor: performance >> Ilde driver: intel_idle >> Idle governor: menu (except teo for one compare test run) >> Idle states: 4: name : description: >> state0/name:POLL desc:CPUIDLE CORE POLL IDLE >> state1/name:C1_ACPI desc:ACPI FFH MWAIT 0x0 >> state2/name:C2_ACPI desc:ACPI FFH MWAIT 0x30 >> state3/name:C3_ACPI desc:ACPI FFH MWAIT 0x60 > > OK, so since the exit residency of an idle state cannot exceed its target > residency, the appended change (on top of 6.18-rc2) should make the throughput > regression go away. Indeed, the patch you appended below did make the throughput regression go away. Thank you. > > --- > drivers/cpuidle/governors/menu.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > --- a/drivers/cpuidle/governors/menu.c > +++ b/drivers/cpuidle/governors/menu.c > @@ -321,10 +321,13 @@ static int menu_select(struct cpuidle_dr > > /* > * Use a physical idle state, not busy polling, unless a timer > - * is going to trigger soon enough. > + * is going to trigger soon enough or the exit latency of the > + * idle state in question is greater than the predicted idle > + * duration. > */ > if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) && > - s->target_residency_ns <= data->next_timer_ns) { > + s->target_residency_ns <= data->next_timer_ns && > + s->exit_latency_ns <= predicted_ns) { > predicted_ns = s->target_residency_ns; > idx = i; > break;