[PATCH 0/3] pmdomain: Improve idlestate selection for CPUs
Ulf Hansson
ulf.hansson at linaro.org
Fri Oct 10 00:52:35 PDT 2025
On Mon, 6 Oct 2025 at 17:36, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> On Fri, Oct 03, 2025 at 05:02:42PM +0200, Ulf Hansson wrote:
> > Platforms using the genpd governor for CPUs are relying on it to find the most
> > optimal idlestate for a group of CPUs. Although, observations tells us that
> > there are some significant improvement that can be made around this.
> >
> > These improvement are based upon allowing us to take pending IPIs into account
> > for the group of CPUs that the genpd governor is in control of. If there is
> > pending IPI for any of these CPUs, we should not request an idlestate that
> > affects the group, but rather pick a shallower state that affects only the CPU.
> >
>
> Thinking about this further, I’m not sure this issue is really specific to
> pmdomain. In my view, the proposed solution could apply equally well to
> platforms that don’t use pmdomain for cpuidle. Also, I don’t see why the
> solution needs to be architecture-specific.
>
> Thoughts ?
>From PSCI PC-mode point of view (I assume that's your main target with
this above comment?), it would *not* make sense to bail out for
idle-states that could affect other CPUs too - because the CPU only
votes itself.
However, if there would be an IPI pending for the current CPU that is
about to enter idle, we should bail out. Although, as stated in the
other thread, we already have the need_resched() thing that helps out
with that, I think.
That said, I think this change is mostly interesting from pmdomain
point of view.
Let me comment on the architecture-specific part in the other thread,
as it seems like Marc also had some comments around that.
>
> I understand it won’t handle all IPI cases, but generic helpers like
> local_softirq_pending() and irq_work_needs_cpu()
> should already cover some of them in a platform-independent way.
Thanks for your suggestion, but unfortunately these don't really help
as they only have information about the current CPU.
Kind regards
Uffe
More information about the linux-arm-kernel
mailing list