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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1ae51ccc-66cc-4551-b649-2f5883e2f5a2@acm.org>
Date: Sun, 23 Mar 2025 05:35:59 -0700
From: Bart Van Assche <bvanassche@....org>
To: "King, Colin" <colin.king@...el.com>,
 Christian Loehle <christian.loehle@....com>, Jens Axboe <axboe@...nel.dk>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
 "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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. How are
users expected to find this configuration option? How should they
decide whether to enable or to disable it?

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@....org/). 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.

Thanks,

Bart.