Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1817571.2o5Kk4Ohv2@kreacher> <2174134.tL5yAn4CWt@kreacher> <20201203124141.GP3021@hirez.programming.kicks-ass.net>
In-Reply-To: <20201203124141.GP3021@hirez.programming.kicks-ass.net>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Thu, 3 Dec 2020 15:44:04 +0100
Message-ID: <CAJZ5v0hhsRmije05gg+Hp2maivoF7i1n33LxYWEnSxhsWV1u=A@mail.gmail.com>
Subject: Re: [RFC][PATCH 1/2] cpufreq: Add special-purpose fast-switching
 callback for drivers
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Linux PM <linux-pm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        Doug Smythies <dsmythies@telus.net>,
        Giovanni Gherdovich <ggherdovich@suse.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Dec 3, 2020 at 1:42 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Nov 30, 2020 at 07:37:01PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > First off, some cpufreq drivers (eg. intel_pstate) can pass hints
> > beyond the current target frequency to the hardware and there are no
>
> Everything CPPC, which is quite a bit these days.

Right, but that is still "some". :-) I can add it to the list of
examples, though.

> > +     /*
> > +      * ->fast_switch() replacement for drivers that use an internal
> > +      * representation of performance levels and can pass hints other than
> > +      * the target performance level to the hardware.
> > +      */
> > +     void            (*adjust_perf)(unsigned int cpu, bool busy,
> > +                                    unsigned long min_perf,
> > +                                    unsigned long target_perf,
> > +                                    unsigned long capacity);
> >
>
> I'm not sure @busy makes sense, that's more a hack because @util had a
> dip and should remain inside schedutil.

So I did it this way, because schedutil would need to store the old
value of target_perf for this and intel_pstate already does that.

But if a new util_hook is used in this case, the existing space in
sg_policy may be used for that.

> > @@ -454,6 +455,25 @@ static void sugov_update_single(struct u
> >       util = sugov_get_util(sg_cpu);
> >       max = sg_cpu->max;
> >       util = sugov_iowait_apply(sg_cpu, time, util, max);
> > +
> > +     /*
> > +      * This code runs under rq->lock for the target CPU, so it won't run
> > +      * concurrently on two different CPUs for the same target and it is not
> > +      * necessary to acquire the lock in the fast switch case.
> > +      */
> > +     if (sg_policy->direct_fast_switch) {
> > +             /*
> > +              * In this case, any optimizations that can be done are up to
> > +              * the driver.
> > +              */
> > +             cpufreq_driver_adjust_perf(sg_cpu->cpu,
> > +                                        sugov_cpu_is_busy(sg_cpu),
> > +                                        map_util_perf(sg_cpu->bw_dl),
> > +                                        map_util_perf(util), max);
> > +             sg_policy->last_freq_update_time = time;
> > +             return;
> > +     }
>
> Instead of adding more branches, would it makes sense to simply set a
> whole different util_hook in this case?

Looks doable without too much code duplication.  Lemme try.