On Wed, Oct 23, 2019 at 10:54 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Wed, Oct 23, 2019 at 4:20 AM Leonard Crestez <leonard.crestez@xxxxxxx> wrote:
> >
> > On 2019-10-23 1:48 AM, Rafael J. Wysocki wrote:
> > > On Wed, Oct 23, 2019 at 12:06 AM Leonard Crestez
> > > <leonard.crestez@xxxxxxx> wrote:
> > >> I've been working on a series which add DEV_PM_QOS support to devfreq,
> > >> now at v9:
> > >>
> > >> Your third patch removes DEV_PM_QOS_FREQUENCY_MIN/MAX that my series
> > >> depends upon. I found the email on patchwork, hopefully the in-reply-to
> > >> header is OK?
> > >>
> > >> As far as I can tell the replacement ("frequency qos") needs constraints
> > >> to be managed outside the device infrastructure and it's not obviously
> > >> usable a generic mechanism for making "min_freq/max_freq" requests to a
> > >> specific device.
> > >
> > > You can add a struct freq_constrants pointer to struct dev_pm_info and
> > > use it just fine. It doesn't have to be bolted into struct
> > > dev_pm_qos.
> >
> > I'm not sure what you mean by this? min/max_freq was already available
> > in dev_pm_qos so it's not clear why it would be moved somewhere else.
> > What I'm looking for is a mechanism to make min/max_freq requests on a
> > per-device basis and DEV_PM_QOS_MIN_FREQUENCY already did that.
> >
> > Reuse is good, right?
>
> But they go away in patch 3 of this series as there are no users in
> the tree. Sorry about that.
>
> > >> I've read a bit through your emails and it seems the problem is that
> > >> you're dealing with dev_pm_qos on per-policy basis but each "struct
> > >> cpufreq_policy" can cover multiple CPU devices.
> > >>
> > >> An alternative solution which follows dev_pm_qos would be to add
> > >> notifiers for each CPU inside cpufreq_online and cpufreq_offline. This
> > >> makes quite a bit of sense because each CPU is a separate "device" with
> > >> a possibly distinct list of qos requests.
> > >
> > > But combining the lists of requests for all the CPUs in a policy
> > > defeats the idea of automatic aggregation of requests which really is
> > > what PM QoS is about.
> >
> > My primary interest is the "dev" part of dev_pm_qos: making pm_qos
> > requests tied to a specific device.
>
> The list of requests needs to be associated with the user of the
> effective constraint. If that is the device, it is all good.
>
> > > There have to be two lists of requests per policy, one for the max and
> > > one for the min frequency >
> > >> If cpufreq needs a group of CPUs to run at the same frequency then it
> > >> should deal with this by doing dev_pm_qos_read_frequency on each CPU
> > >> device and picking a frequency that attempts to satisfy all constraints.
> > >
> > > No, that would be combining the requests by hand.
> >
> > It's just a loop though.
>
> Yes, it is, and needs to be run on every change of an effective
> constraint for any CPU even if the total effective constraint doesn't
> change. And, of course, the per-policy user space limits would need
> to be combined with that by hand.
>
> Not particularly straightforward if you asked me.
>
> Not to mention the fact that, say, cpu_cooling, has a per-policy list
> of requests anyway.
A per-policy request, not a list of them. Sorry.
