Re: [PATCH] cpuidle: psd: add power sleep demotion prevention for fast I/O devices

[Rafael J. Wysocki]

On Wed, Mar 26, 2025 at 4:04 PM King, Colin <colin.king@xxxxxxxxx> wrote:
>
> Hi,
>
> > -----Original Message-----
> > From: Bart Van Assche <bvanassche@xxxxxxx>
> > Sent: 23 March 2025 12:36
> > To: King, Colin <colin.king@xxxxxxxxx>; Christian Loehle
> > <christian.loehle@xxxxxxx>; Jens Axboe <axboe@xxxxxxxxx>; Rafael J.
> > Wysocki <rafael@xxxxxxxxxx>; Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>;
> > linux-block@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx
> > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH] cpuidle: psd: add power sleep demotion prevention for
> > fast I/O devices
> >
> > On 3/17/25 3:03 AM, King, Colin wrote:
> > > This code is optional, one can enable it or disable it via the config
> > > option. Also, even when it is built-in one can disable it by writing 0 to the
> > sysfs file
> > >    /sys/devices/system/cpu/cpuidle/psd_cpu_lat_timeout_ms
> >
> > I'm not sure we need even more configuration knobs in sysfs.
>
> It's useful for enabling / disabling the functionality, as well as some form of tuning for slower I/O devices, so I think it is justifiable.
>
> > How are users
> > expected to find this configuration option? How should they decide whether
> > to enable or to disable it?
>
> I can send a V2 with some documentation if that's required.

It would be useful because the original patch didn't get to linux-pm
(among other things).

> >
> > Please take a look at this proposal and let me know whether this would solve
> > the issue that you are looking into: "[LSF/MM/BPF Topic] Energy- Efficient I/O"
> > (https://lore.kernel.org/linux-block/ad1018b6-7c0b-4d70-
> > b845-c869287d3cf3@xxxxxxx/). The only disadvantage of this approach
> > compared to the cpuidle patch is that it requires RPM (runtime power
> > management) to be enabled. Maybe I should look into modifying the
> > approach such that it does not rely on RPM.
>
> I've had a look, the scope of my patch is a bit wider.  If my patch gets accepted I'm
> going to also look at putting the psd call into other devices (such as network devices) to
> also stop deep states while these devices are busy.  Since the code is very lightweight I
> was hoping this was going to be relatively easy and simple to use in various devices in the future.

But I'm generally wondering why this is using a completely new
mechanism instead of CPU latency QoS which is there and why is menu
the only governor targeted by it?