[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0j3zPJEi668m4Gmf_0Z+6pyg4=HXTVuNJ4FwzZJWbVcYQ@mail.gmail.com>
Date: Wed, 26 Mar 2025 16:14:28 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "King, Colin" <colin.king@...el.com>
Cc: Bart Van Assche <bvanassche@....org>, 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>,
"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 Wed, Mar 26, 2025 at 4:04 PM King, Colin <colin.king@...el.com> wrote:
>
> Hi,
>
> > -----Original Message-----
> > From: Bart Van Assche <bvanassche@....org>
> > Sent: 23 March 2025 12:36
> > 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-pm@...r.kernel.org
> > Cc: 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.
>
> 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@....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.
>
> 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?
Powered by blists - more mailing lists