From nobody Wed Dec 17 17:43:18 2025 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 76E1A320CDF for ; Mon, 20 Oct 2025 14:17:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760969856; cv=none; b=PWxKMQmZiy5UmnKV/h5cPnPVy3GryS0NxpF0IjnQfdEMuh07qDhn8CCNm+d3Pfm0YEEx9fZt+2YH9foV2Wiwp0Fmu0FAWZJD/HqnfQV8rIAcgWUvofWry8zDPPq9hF7QDL6hyOjkTHwmRfTFYzPh83vDAv2sHursbcR1H0Y7N1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760969856; c=relaxed/simple; bh=eCdD6Rchcv/zsQaGx/OdGmxf9oXHMxScoB0zys5/ino=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DPeoRcVtJheA7/Y5jpe4ZgfF8QkpAHuC0ZId01yU6+VR45FNun8CXmMPEx/2wQHBM02TFcVvaHaLG9hsntF0VWxPO+zCUuBFDiw3ICW2hAw5oZEYWmMfk6nnTRxZrEhY8kSesNQgouk1boOYwVymd9ejBSJWI33n6H0yBUC7tZo= 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=fYkgzrz+; arc=none smtp.client-ip=209.85.167.44 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="fYkgzrz+" Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-591c74fd958so5561548e87.3 for ; Mon, 20 Oct 2025 07:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1760969853; x=1761574653; 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=0dIjv4MSR8RQ0lSEv7ckZWWm3B4P0BM3xvQjsLdtr2E=; b=fYkgzrz+DE4Rr8AQlZr5pw+0F61dyLcX8QvxjQ/cPsVuK6mwTM9w6teN8jjORE+DZ+ uLxTP0/z34waFD10GyU5iv581wbw9alCCuns0Zwbf2H74a10bqWi/VWw8dIvRz6x/ogB dwG6tVMTH34iYwEy7vYlc8/ocofePB+M9Lmm/BBpf8gg8OWH7eTXak0hNUX+/VUyq5Vw BkAWk/r2Y5ozo7uyuiLuiO8HHCIWwB8fLCa6pqRUpPBxrWf3Sl90FSMAQCirihO1JcF7 5cF4/Y71XWjXx2xHJqE3G9FCEAoIvIPXsIXu7+Mx+DS+gUuOOItlzY5iiTeBw0nsAMg/ F0Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760969853; x=1761574653; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0dIjv4MSR8RQ0lSEv7ckZWWm3B4P0BM3xvQjsLdtr2E=; b=jRPHSCO6NnaIJwTzsWkKF26Cuyn19VhkLLjt+X/tlVQVV/KelYl/ubNMzBT50zBViO 8VuAN4EYJcvRBB/ikFg0XJmdHkJxAKhV8VXDjGpfAq5fleREyKeFu5YBBeNl5CXQcZ2W /fWVWz5kxIIfSEK6nscXWKXNP/33leSII0F+bcr+WpfqwZaFIy4SGJ+R6cSmKBbehwo7 6FvexrnOaJ2l5iR2mPsKmwzf4u26G/IDVuLkwxbpmHQJbdbPeQJUgyY9EWVLSl9QP1V4 pVz6hKsxJ3BTW2lvlPiLlTu2z3fuiTW0PlxBg7cATueDiKeA+4d1kduFFABWyf+rBagX K7ew== X-Forwarded-Encrypted: i=1; AJvYcCXZPSSQ2z3kMu2QYpmsM2tZwITfkZoYJqedMqz6XQfcD//tG17vCfJk/b5xVj7Cgs4qz0t6LYP/kRTbNuw=@vger.kernel.org X-Gm-Message-State: AOJu0YwvuyxLsYgdUWDD5JtNlRehQi30TaS+U7pddbELADe1yUzIBT0g yTwhZLzVXwpUgrrKDipjAk2ttA8IjohHsGNxaZQkkRZV4wtJS/iunqVP4oWzlAVCOzs= X-Gm-Gg: ASbGncsvkOaV+pZEzrfITEh+impJkMwWMkik62BnWVr6fpaBiiRwHZGdOL/OT3sP9NF Zs2hVHqSEbQyiVyOIsAqR2XsKczbf8g8czewt1D34JwMWP94KRfRPD22v4WIlFNpOoO/qheYzFZ W4fSZgc8WB5YkprcDi/vwog91LDU2EXDHun0y2LHG8nhRuf4A90ogIKwMQmu4HsklsT9y/s0E6y KMMza5YLVTFdypjQCxGFURtFI7P8FqHy/c9pQ1Lcrld5bhiJXwvJlfStBNiHby+m+5TqKmJbx7+ GgGDT+uGwFS6M4thcYS+aYH59Zssejq+RBUTe0Jj+NWpgoyNVbQzcegxqK+WwbtlDU4sHUnXGFU /86b9D0n4ikGX+R1agQG2txpbnu+3GnfhH49DEPiYIKUi/AzT6if3nHINsA1hSrpjfx0gJ8fXcp hqs5Co3iTgRqBaRzdGgu1sJct566yQS/hiSVx1kYOb+XEjpF/GnQ== X-Google-Smtp-Source: AGHT+IFC52orDQWOlIL6EQhuSMEzlEpPeXgxvFXygwzJXEOK1ypBXTxDyX/2RUJkJkcU3BSkgxWjfw== X-Received: by 2002:a05:651c:892:b0:36b:b0eb:9d65 with SMTP id 38308e7fff4ca-37797815ebfmr36900691fa.10.1760969852425; Mon, 20 Oct 2025 07:17:32 -0700 (PDT) Received: from uffe-tuxpro14.. (h-178-174-189-39.A498.priv.bahnhof.se. [178.174.189.39]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-377a950a284sm20797191fa.36.2025.10.20.07.17.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Oct 2025 07:17:31 -0700 (PDT) From: Ulf Hansson To: "Rafael J . Wysocki" , Thomas Gleixner Cc: Mark Rutland , Marc Zyngier , Maulik Shah , Sudeep Holla , Daniel Lezcano , Vincent Guittot , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Ulf Hansson Subject: [PATCH v2 1/2] smp: Introduce a helper function to check for pending IPIs Date: Mon, 20 Oct 2025 16:17:11 +0200 Message-ID: <20251020141718.150919-2-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251020141718.150919-1-ulf.hansson@linaro.org> References: <20251020141718.150919-1-ulf.hansson@linaro.org> 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" When governors used during cpuidle, tries to find the most optimal idlestate for a CPU or a group of CPUs, they are known to quite often fail. One reason for this, is that we are not taking into account whether there has been an IPI scheduled for any of the CPUs that are affected by the selected idlestate. To enable pending IPIs to be taken into account for cpuidle decisions, let's introduce a new helper function, cpus_may_have_pending_ipi(). Note that, the implementation is intentionally as lightweight as possible, in favor of always providing the correct information. For cpuidle decisions this is good enough. Suggested-by: Thomas Gleixner Signed-off-by: Ulf Hansson --- Changes in v2: - Implemented a common function, rather than making it arch-specific. As suggested by Thomas and Marc. - Renamed the function to indicate that it doesn't provide correctness. - Clarified function description and commit message. --- include/linux/smp.h | 5 +++++ kernel/smp.c | 24 ++++++++++++++++++++++++ 2 files changed, 29 insertions(+) diff --git a/include/linux/smp.h b/include/linux/smp.h index 18e9c918325e..093e5458493e 100644 --- a/include/linux/smp.h +++ b/include/linux/smp.h @@ -168,6 +168,7 @@ int smp_call_function_any(const struct cpumask *mask, =20 void kick_all_cpus_sync(void); void wake_up_all_idle_cpus(void); +bool cpus_may_have_pending_ipi(const struct cpumask *mask); =20 /* * Generic and arch helpers @@ -216,6 +217,10 @@ smp_call_function_any(const struct cpumask *mask, smp_= call_func_t func, =20 static inline void kick_all_cpus_sync(void) { } static inline void wake_up_all_idle_cpus(void) { } +static inline bool cpus_may_have_pending_ipi(const struct cpumask *mask) +{ + return false; +} =20 #define setup_max_cpus 0 =20 diff --git a/kernel/smp.c b/kernel/smp.c index 02f52291fae4..775f90790935 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -1087,6 +1087,30 @@ void wake_up_all_idle_cpus(void) } EXPORT_SYMBOL_GPL(wake_up_all_idle_cpus); =20 +/** + * cpus_may_have_pending_ipi - Check for pending IPIs for CPUs + * @mask: The CPU mask for the CPUs to check. + * + * This function walks through the @mask to check if there are any pending= IPIs + * scheduled, for any of the CPUs in the @mask. + * + * It's important for the caller to know that this function does not guara= ntee + * correctness, as the intent is to be as lightweight as possible. + * + * Returns true if there is a pending IPI scheduled and false otherwise. + */ +bool cpus_may_have_pending_ipi(const struct cpumask *mask) +{ + unsigned int cpu; + + for_each_cpu(cpu, mask) { + if (!llist_empty(per_cpu_ptr(&call_single_queue, cpu))) + return true; + } + + return false; +} + /** * struct smp_call_on_cpu_struct - Call a function on a specific CPU * @work: &work_struct --=20 2.43.0 From nobody Wed Dec 17 17:43:18 2025 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (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 11EC6326D70 for ; Mon, 20 Oct 2025 14:17:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760969858; cv=none; b=XXcK1G7Tj4q/W/HaZAad4l2dZ00DUpxz43UvpaLMKdSydVLnhTKNYR0qm+11SgJFDaRzACcIYIEJLOBh2u5X2kFGMf+l7VjSMCEmLsAuqRC5eCH+4GWdRL2dc/LSKnRlqZ2s8WBpd4nVIAePAAS+4I/ogNh8tDHnEGIq8gJd8/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760969858; c=relaxed/simple; bh=TCMur3W305UYpjzmNzxUmoJ7pqZkPL+65/d3pRVJ+8c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XBXOvn4BB9v6gCwl0LQJtWU0so7oEf3375Fer7XwSFumYxqPYzWEDrQafFFOjdVuLMzPs9YRklEysijw1LQzBkBDwUttGTM+t8faEGlv5Q8LMgJWNkb9x6xiSYJC7w6ZiGznYisYH86SQhn6naJVWkAWfNd9e85N4k7H5Hij6Hs= 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=ixUr9Y4S; arc=none smtp.client-ip=209.85.208.181 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="ixUr9Y4S" Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-37777912136so42141511fa.0 for ; Mon, 20 Oct 2025 07:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1760969854; x=1761574654; 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=fGaC808GWK5LvOXihoY32Hd24hri1xoqdM6UgzacKUw=; b=ixUr9Y4Sh6v6YYTOQawMpC/lJfrwXd/gWXfFqlgPz2/9ItwKXVtTUCLjaDlAyezL4Q nJy0UhPcpre2dq00g4uOpiY84GSqiqXJhLYCFYvwzV4tajLpe1q4ZadayYNensp6YfgE khlwmOpt6VGgj+aL3uvRNlHgYb4paXpEZhTKz9Ea56f9475HWmNZEMXf/tb7hgj5aR+Y /QQtqj4q//K/Sa+KfmhHZJr4XfQqKftwIQuEuHJr+ltBAcs47Qko6bNK7mg9au2IyUdc vDM27JMIXtLzb2n0Nm0vMTbL58CtqVM8Y0Kmygpl8tplghWxDitWMDlJHGXYS+7yGG+z kRMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760969854; x=1761574654; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fGaC808GWK5LvOXihoY32Hd24hri1xoqdM6UgzacKUw=; b=XAYEIsnWpbFAcjrTDMGy8dqgIvCvQERZHFr8tNxTHXg3NFGUYmZrU8qiwdnZ3XuRAE 9sPjO3OePnDbjyxkSyynI9n1h/5BLFsuqJ5EX8qFarByBkn7zKujcFuONiUEm0sdzeAK J0QzAMlT5/a+/aK96/DU/JsWMLiTeU+kSWZMDcFnX1Iun8gik+Jpy1rYduI+QB82ZiQ/ XH4RjPC7PW55DbBHUdSn19ai4Py7XPIe3PjFYmjqdirVVez8hd1hL1nBG0nkx9bAyeyU J/cdzPp6YKhhDxubkq67pLl14k5SLGN+oHRNQQmmjR30xBOGVixXD8Z7vKz9JQ8GKXk6 KZ5A== X-Forwarded-Encrypted: i=1; AJvYcCWnxW885Oitk+Cu9+1hS896ZsUpn0Aj63e+qfweXpsXA7SH+y02myY7YidP0u5UXakxXjx57fio3RgC/bw=@vger.kernel.org X-Gm-Message-State: AOJu0YwNwrJUkGIg0KdshjtjNTFN0GmFGBCs4/i1PZ9FcHYYAHgAjVHu UmizhxeigC5gy66lcM1iaT9YGOJVtbLm3OhZwqtyUff96vgR05gs8uC++J9l7jLm6n/yRSKYPD/ gs6fk X-Gm-Gg: ASbGncva0OxzgEN5pn6dL32fm26ec9QG8E+MPDJsf79mYxNQO4h2JiYPQQ++I92a0kW qFY9nQkdZ+RO1j+twvqlpXBgazVLzM4DAe0fPSy0LERkyh8NNI/acyt94oB29MquuyJtwD2/1WK r2j+yxUh9sz46uAahouKrpUhnFqXzebvalKjoZPIUzJbKwotpeEDjaWlkPz6bm6xF9dKK3xQxdJ QPPshriYjlCW4skvWSplQdYMrLxgZr/3eMu+b1iNNOVhZcgNSetuY5rM/kZhKyuvqyUWH0xow8Q t1zmuymFVMEcxsoisygvbL7Sd06UBK/5O92sbPCp9MNB5llsx+yD9DC1QtkdIyGV08p5jPX4SpS yAaKOiwXytgzSkPofKey99io9xKr3N4hxkqLhFgRwpAM3cuNp8LUZHhXPQGzuCBAuY1WopGox+z mf7wh6EfD1VX0g+XCbGKzzvrLeZe/44oMggAjkIgIQaiGwv3qt2g0x/PwpMtxj X-Google-Smtp-Source: AGHT+IHq+N7kJam9BA4Q2VZUWH3bExEE+I696f8s201sUzMH8M2RHkReQkfdKWnv543fHUx9gbKhQg== X-Received: by 2002:a05:651c:2343:20b0:377:c5b7:7bbd with SMTP id 38308e7fff4ca-377c5b77c4emr4089701fa.15.1760969853955; Mon, 20 Oct 2025 07:17:33 -0700 (PDT) Received: from uffe-tuxpro14.. (h-178-174-189-39.A498.priv.bahnhof.se. [178.174.189.39]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-377a950a284sm20797191fa.36.2025.10.20.07.17.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Oct 2025 07:17:33 -0700 (PDT) From: Ulf Hansson To: "Rafael J . Wysocki" , Thomas Gleixner Cc: Mark Rutland , Marc Zyngier , Maulik Shah , Sudeep Holla , Daniel Lezcano , Vincent Guittot , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Ulf Hansson Subject: [PATCH v2 2/2] pmdomain: Extend the genpd governor for CPUs to account for IPIs Date: Mon, 20 Oct 2025 16:17:12 +0200 Message-ID: <20251020141718.150919-3-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251020141718.150919-1-ulf.hansson@linaro.org> References: <20251020141718.150919-1-ulf.hansson@linaro.org> 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" When the genpd governor for CPUs, tries to select the most optimal idlestate for a group of CPUs managed in a PM domain, it fails far too often. On a Dragonboard 410c, which is an arm64 based platform with 4 CPUs in one cluster that is using PSCI OS-initiated mode, we can observe that we often fail when trying to enter the selected idlestate. This is certainly a suboptimal behaviour that leads to many unnecessary requests being sent to the PSCI FW. A simple dd operation that reads from the eMMC, to generate some IRQs and I/O handling helps us to understand the problem, while also monitoring the rejected counters in debugfs for the corresponding idlestates of the genpd in question. Menu governor: cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 1451 437 91 149 0 S1 65194 558 149 172 0 dd if=3D/dev/mmcblk0 of=3D/dev/null bs=3D1M count=3D500 524288000 bytes (500.0MB) copied, 3.562698 seconds, 140.3MB/s cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 2694 1073 265 892 1 S1 74567 829 561 790 0 The dd completed in ~3.6 seconds and rejects increased with 586. Teo governor: cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 4976 2096 392 1721 2 S1 160661 1893 1309 1904 0 dd if=3D/dev/mmcblk0 of=3D/dev/null bs=3D1M count=3D500 524288000 bytes (500.0MB) copied, 3.543225 seconds, 141.1MB/s cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 5192 2194 433 1830 2 S1 167677 2891 3184 4729 0 The dd completed in ~3.6 seconds and rejects increased with 1916. The main reason to the above problem is pending IPIs for one of the CPUs that is affected by the idlestate that the genpd governor selected. This leads to that the PSCI FW refuses to enter it. To improve the behaviour, let's start to take into account pending IPIs for CPUs in the genpd governor, hence we fallback to use the shallower per CPU idlestate. Re-testing with this change shows a significant improved behaviour. - Menu governor: cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 2556 878 19 368 1 S1 69974 596 10 152 0 dd if=3D/dev/mmcblk0 of=3D/dev/null bs=3D1M count=3D500 524288000 bytes (500.0MB) copied, 3.522010 seconds, 142.0MB/s cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 3360 1320 28 819 1 S1 70168 710 11 267 0 The dd completed in ~3.5 seconds and rejects increased with 10. - Teo governor cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 5145 1861 39 938 1 S1 188887 3117 51 1975 0 dd if=3D/dev/mmcblk0 of=3D/dev/null bs=3D1M count=3D500 524288000 bytes (500.0MB) copied, 3.653100 seconds, 136.9MB/s cat /sys/kernel/debug/pm_genpd/power-domain-cluster/idle_states State Time Spent(ms) Usage Rejected Above Below S0 5260 1923 42 1002 1 S1 190849 4033 52 2892 0 The dd completed in ~3.7 seconds and rejects increased with 4. Note that, the rejected counters in genpd are also being accumulated in the rejected counters that are managed by cpuidle, yet on a per CPU idlestates basis. Comparing these counters before/after this change, through cpuidle's sysfs interface shows the similar improvements. Signed-off-by: Ulf Hansson --- Changes in v2: - Use the new name of the helper function. - Re-test and update the statistics in the commit message. --- drivers/pmdomain/governor.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/drivers/pmdomain/governor.c b/drivers/pmdomain/governor.c index 39359811a930..ed2ce9b6f8d1 100644 --- a/drivers/pmdomain/governor.c +++ b/drivers/pmdomain/governor.c @@ -404,15 +404,21 @@ static bool cpu_power_down_ok(struct dev_pm_domain *p= d) if ((idle_duration_ns >=3D (genpd->states[i].residency_ns + genpd->states[i].power_off_latency_ns)) && (global_constraint >=3D (genpd->states[i].power_on_latency_ns + - genpd->states[i].power_off_latency_ns))) { - genpd->state_idx =3D i; - genpd->gd->last_enter =3D now; - genpd->gd->reflect_residency =3D true; - return true; - } + genpd->states[i].power_off_latency_ns))) + break; + } while (--i >=3D 0); =20 - return false; + if (i < 0) + return false; + + if (cpus_may_have_pending_ipi(genpd->cpus)) + return false; + + genpd->state_idx =3D i; + genpd->gd->last_enter =3D now; + genpd->gd->reflect_residency =3D true; + return true; } =20 struct dev_power_governor pm_domain_cpu_gov =3D { --=20 2.43.0