* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > As it is currently the kernel doesn't need to know anything about the
> > semantics of individual counters being selected, so it's currently convenient
> > that we can aim to maintain all the counter meta data we have in userspace
> > according to the changing needs of tools or drivers (e.g. names, descriptions,
> > units, max values, normalization equations), de-coupled from the kernel,
> > instead of splitting it between the kernel and userspace.
>
> And that fully violates the design premise of perf. The kernel should be in
> control of resources, not userspace.
>
> If we'd have put userspace in charge, we could now not profile the same task by
> two (or more) different observers. But with kernel side counter management that
> is no problem at all.
Beyond that there are a couple of other advantages of managing performance metrics
via the kernel:
2)
Per task/workload/user separation of events, for example you can do:
perf record make bzImage
perf stat make bzImage
These will only profile/count in the child task hierarchy spawned by the shell.
Multiple such sessions can be started and the perf sampling/counting of the
separate workloads is independent of each other.
3)
Finegrained security model: you can chose which events to expose to what privilege
levels. You can also work around hardware bugs without complicating tooling.
4)
Seemless integration of the various PMU and other event metrics with each other:
you can start a CPU PMU event, a trace event, a software event and an uncore
event, which all output into the same coherent, ordered ring-buffer, timestamped
and correlated consistently, etc.
5)
The unified event model on the kernel side also brings with itself 100 KLOC of
rich, unified tooling in tools/perf/, which tries to keep it all together and
functional.
================
The cost of all that is having to implement kernel support for it, but once that
initial hurdle is taken, it's well worth it! A PMU driver can be as simple as
offering only a single system-wide counter.
Thanks,
Ingo
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
