Em Tue, Nov 17, 2015 at 08:31:11AM -0500, Frank Ch. Eigler escreveu:
> Hi -
>
> > >> global s, t%
> > >> probe kernel.trace("foobar_enter") {
> > >> t[tid()]=gettimeofday_us()
> > >> }
> > >> probe kernel.trace("foobar_exit") {
> > >> if (tid() in t) { s <<< gettimeofday_us() - t[tid()] }
> > >> }
> > >> probe timer.s(5),end {
> > >> printf("cumulative average us: %d\n", @avg(s))
> > >> }
> > > [...]
> >
> > Interesting solution. How does it scale with CPUs and tasks?
>
> It's not a simple question, as there are several factors, but
> generally fine.
>
> systemtap compiles down to native code, so execution is very fast and
> CPU consumption is not a problem (better than streaming to userspace &
> processing there).
That "better' is also not a simple answer, as there are several factors
:-)
Anyway, those are different methods, applicable to different scenarios
and sets of constraints, sometimes only one of these tools can be used,
due to these constraints, sometimes one can try several and see how they
fare.
- Arnaldo
> Depending on actual runtime behavior, there may be contention over the
> t[] array that tracks start-time. systemtap automagically safely
> locks these for correctness. If contention is high, trylock/timeouts
> can fail and some probes will be missed. Fail too many and the script
> will self-terminate. (See [man stap] for some of the related
> configurables.)
>
> There is no contention over the s scalar value tracks elapsed time,
> since it is implicitly aggregated on a per-cpu basis. That scales
> without problem.
>
> - FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
