From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Doug Smythies <doug.smythies@gmail.com>
Cc: dsmythies@telus.net, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org
Subject: Re: [PATCH V5] cpufreq: intel_pstate: allow trace in passive mode
Date: Mon, 14 May 2018 08:35:41 -0700 [thread overview]
Message-ID: <1526312141.61700.5.camel@linux.intel.com> (raw)
In-Reply-To: <3708753.N4DSO893cq@aspire.rjw.lan>
On Sun, 2018-05-13 at 10:43 +0200, Rafael J. Wysocki wrote:
> On Thursday, May 3, 2018 8:22:47 AM CEST Doug Smythies wrote:
> > Allow use of the trace_pstate_sample trace function
> > when the intel_pstate driver is in passive mode.
> > Since the core_busy and scaled_busy fields are not
> > used, and it might be desirable to know which path
> > through the driver was used, either intel_cpufreq_target
> > or intel_cpufreq_fast_switch, re-task the core_busy
> > field as a flag indicator.
> >
> > The user can then use the intel_pstate_tracer.py utility
> > to summarize and plot the trace.
> >
> > Note: The core_busy feild still goes by that name
> > in include/trace/events/power.h and within the
> > intel_pstate_tracer.py script and csv file headers,
> > but it is graphed as "performance", and called
> > core_avg_perf now in the intel_pstate driver.
> >
> > Sometimes, in passive mode, the driver is not called for
> > many tens or even hundreds of seconds. The user
> > needs to understand, and not be confused by, this limitation.
> >
> > Signed-off-by: Doug Smythies <dsmythies@telus.net>
>
> Srinivas, any comments or concerns?
>
Looks fine. But as rest of code, prefer a newline after return.
So I am sending V6 version only with that change.
Thanks,
Srinivas
> >
> > ---
> >
> > V5: Changes as per Rafael J. Wysocki feedback.
> > See: https://lkml.org/lkml/2018/1/7/270
> >
> > V4: Only execute the trace specific overhead code if trace
> > is enabled. Suggested by Srinivas Pandruvada.
> >
> > V3: Move largely duplicate code to a subroutine.
> > Suggested by Rafael J. Wysocki.
> >
> > V2: prepare for resend. Rebase to current kernel, 4.15-rc3.
> >
> > ---
> > drivers/cpufreq/intel_pstate.c | 44
> > ++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 42 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 17e566af..4a08686 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -1939,13 +1939,49 @@ static int
> > intel_cpufreq_verify_policy(struct cpufreq_policy *policy)
> > return 0;
> > }
> >
> > +/* Use of trace in passive mode:
> > + *
> > + * In passive mode the trace core_busy field (also known as the
> > + * performance field, and lablelled as such on the graphs; also
> > known as
> > + * core_avg_perf) is not needed and so is re-assigned to indicate
> > if the
> > + * driver call was via the normal or fast switch path. Various
> > graphs
> > + * output from the intel_pstate_tracer.py utility that include
> > core_busy
> > + * (or performance or core_avg_perf) have a fixed y-axis from 0 to
> > 100%,
> > + * so we use 10 to indicate the the normal path through the
> > driver, and
> > + * 90 to indicate the fast switch path through the driver.
> > + * The scaled_busy field is not used, and is set to 0.
> > + */
> > +
> > +#define INTEL_PSTATE_TRACE_TARGET 10
> > +#define INTEL_PSTATE_TRACE_FAST_SWITCH 90
> > +
> > +static void intel_cpufreq_trace(struct cpudata *cpu, unsigned int
> > trace_type, int old_pstate)
> > +{
> > + struct sample *sample;
> > +
> > + if (!trace_pstate_sample_enabled())
> > + return;
one newline
> > + if (!intel_pstate_sample(cpu, ktime_get()))
> > + return;
one new line
> > + sample = &cpu->sample;
> > + trace_pstate_sample(trace_type,
> > + 0,
> > + old_pstate,
> > + cpu->pstate.current_pstate,
> > + sample->mperf,
> > + sample->aperf,
> > + sample->tsc,
> > + get_avg_frequency(cpu),
> > + fp_toint(cpu->iowait_boost * 100));
> > +}
> > +
> > static int intel_cpufreq_target(struct cpufreq_policy *policy,
> > unsigned int target_freq,
> > unsigned int relation)
> > {
> > struct cpudata *cpu = all_cpu_data[policy->cpu];
> > struct cpufreq_freqs freqs;
> > - int target_pstate;
> > + int target_pstate, old_pstate;
> >
> > update_turbo_state();
> >
> > @@ -1965,12 +2001,14 @@ static int intel_cpufreq_target(struct
> > cpufreq_policy *policy,
> > break;
> > }
> > target_pstate = intel_pstate_prepare_request(cpu,
> > target_pstate);
> > + old_pstate = cpu->pstate.current_pstate;
> > if (target_pstate != cpu->pstate.current_pstate) {
> > cpu->pstate.current_pstate = target_pstate;
> > wrmsrl_on_cpu(policy->cpu, MSR_IA32_PERF_CTL,
> > pstate_funcs.get_val(cpu,
> > target_pstate));
> > }
> > freqs.new = target_pstate * cpu->pstate.scaling;
> > + intel_cpufreq_trace(cpu, INTEL_PSTATE_TRACE_TARGET,
> > old_pstate);
> > cpufreq_freq_transition_end(policy, &freqs, false);
> >
> > return 0;
> > @@ -1980,13 +2018,15 @@ static unsigned int
> > intel_cpufreq_fast_switch(struct cpufreq_policy *policy,
> > unsigned int
> > target_freq)
> > {
> > struct cpudata *cpu = all_cpu_data[policy->cpu];
> > - int target_pstate;
> > + int target_pstate, old_pstate;
> >
> > update_turbo_state();
> >
> > target_pstate = DIV_ROUND_UP(target_freq, cpu-
> > >pstate.scaling);
> > target_pstate = intel_pstate_prepare_request(cpu,
> > target_pstate);
> > + old_pstate = cpu->pstate.current_pstate;
> > intel_pstate_update_pstate(cpu, target_pstate);
> > + intel_cpufreq_trace(cpu, INTEL_PSTATE_TRACE_FAST_SWITCH,
> > old_pstate);
> > return target_pstate * cpu->pstate.scaling;
> > }
> >
> >
>
>
next prev parent reply other threads:[~2018-05-14 15:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 6:22 [PATCH V5] cpufreq: intel_pstate: allow trace in passive mode Doug Smythies
2018-05-13 8:43 ` Rafael J. Wysocki
2018-05-14 15:35 ` Srinivas Pandruvada [this message]
2018-05-15 9:05 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1526312141.61700.5.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=doug.smythies@gmail.com \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.