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?
