On Tue, Nov 04, 2014 at 03:25:27PM +, Pawel Moll wrote:
> Very good idea, should have came up with it myself :-)
>
> Does __setup("perf_use_local_clock") sound reasonable?
Would not the 'module' already prefix a perf.? I never quite know how
all that works out. But sure, that works.
> Then w
On Tue, 2014-11-04 at 07:23 +, Peter Zijlstra wrote:
> On Tue, Nov 04, 2014 at 12:28:36AM +, Pawel Moll wrote:
>
> > +int sysctl_perf_sample_time_clk_id = CLOCK_MONOTONIC;
>
> const ?
Sure (unless we have to change it as mentioned below)
> > /*
> > * perf samples are done in some ver
On Tue, Nov 04, 2014 at 12:28:36AM +, Pawel Moll wrote:
> +int sysctl_perf_sample_time_clk_id = CLOCK_MONOTONIC;
const ?
> /*
> * perf samples are done in some very critical code paths (NMIs).
> * If they take too much CPU time, the system can lock up and not
> @@ -324,7 +326,7 @@ exter
Until now, perf framework never defined the meaning of the timestampt
captured as PERF_SAMPLE_TIME sample type. The values were obtaining
from local (sched) clock, which is unavailable in userspace. This made
it impossible to correlate perf data with any other events. Other
tracing solutions have t
4 matches
Mail list logo