[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1515186406.26317.38.camel@linux.intel.com>
Date: Fri, 05 Jan 2018 13:06:46 -0800
From: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To: Doug Smythies <dsmythies@...us.net>,
"'Rafael J. Wysocki'" <rafael@...nel.org>
Cc: "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>,
'Linux PM' <linux-pm@...r.kernel.org>
Subject: Re: [Resend][PATCH V2] cpufreq: intel_pstate: allow trace in
passive mode
On Fri, 2018-01-05 at 12:15 -0800, Doug Smythies wrote:
> >
[...]
> On 2017.12.18 16:25 Rafael J. Wysocki wrote:
> > > > + from = cpu->pstate.current_pstate;
> > > > + time = ktime_get();
> > > > + sample_taken = intel_pstate_sample(cpu, time);
> > > > +
> > > This is quite a bit of overhead for tracing.
> Yes, it is a bit of added code, but without tracing abilities I
> do not know how to investigate passive operation.
>
> >
> > >
> > > Why not fold the above two
> > > statements in the next if () with conditional tracing?
> No, I specifically want to do a trace sample, even if the target
> is the same as last time. Why? Because we want to know the time
> between calls to the driver, i.e. the duration. That information
> is incredibly useful.
I am not saying you don't need trace. But you can do all processing
when just trace is enabled. Which can be done by
if (trace_pstate_sample_enabled())
The above function should return true when trace is enabled.
So in your v3,
in intel_cpufreq_trace() you can simply return if
trace_pstate_sample_enabled() is false, without
calling intel_pstate_sample().
Thanks,
Srinivas
Powered by blists - more mailing lists