Re: Performance counter API review was [patch] PerformanceCounters for Linux, v3

[Paul Mackerras]

Peter Zijlstra writes:

> Doing a single fd for all cpus is going to suck chunks because its going
> to be a global serialization point.

If we need statistics for the system as a whole (and we do), then the
serialization is going to happen somewhere - the only question is
whether it's in the kernel or in userspace.  I don't see that it needs
to be a _global_ serialization point in either case.  Given that the
kernel has facilities like smp_call_function() available that
userspace doesn't, I think it will end up cleaner to do it in the
kernel.

That's actually a bit independent of whether it should be accessed via
one fd or multiple fds.  One alternative might be to use something
analogous to the counter group concept we have (i.e. multiple fd's,
but have a way to logically join them together).

By the way, how does userspace get to know about cpus being added or
removed?  Is there a better way than continually reading
/sys/devices/system/cpu/online?

> Also, why would you be profiling while doing a hotplug? Both cpu
> profiling, and hotplug, are administrator operations, just don't do
> that.

Performance counters are also used for counting, which by definition
is something that takes place over a period of time, possibly quite a
long time.  It would be annoying to have to stop counting and start a
new count every time we need to plug or unplug a cpu.

> The inheritance thing will also suffer this issue, if you're going to do
> reads of your fds at any other point than at the end -- it will have to
> walk the whole inheritance tree and sum all the values (or propagate
> interrupts up the tree). Which sounds rather expensive.

I'm planning to make that operation (summing over all children) be
something that userspace can request via an ioctl, so userspace gets
to decide when and how often it's worth the expense of doing it.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/