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

[Paul Mackerras <paulus@samba.org>]

Peter Zijlstra writes:

> How is smp_call_function() going to help here? You still need to pull
> all that data through that one FD. That's a cacheline bounce fest.

Well, let's put this into perspective.  We would be collecting 8 bytes
of data from each CPU.  Hardly a "cacheline bounce fest". :)

> Why not collect all this data with per-cpu threads and post-process in
> user-space. The processing might even be capable of doing per-cpu
> filtering, reducing the amount of data that needs to be merged.
> 
> No way that's better done in the kernel.

Not quite sure why you think there's an enormous volume of data to be
managed...

> > > 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.
> 
> Well, you need to at least stop/start the cpu to be hot-(un)plugged, no
> way around that.

It might be worth having the kernel do that automatically, given that
the perfcounters code already has a hotplug notifier routine.
However, I don't think this point is worth debating until we have a
more concrete proposal.

> > 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.
> 
> Userspace already has that control, you don't have to read the counter
> before you get SIGCHLD.
> 
> I'm not seeing how an ioctl will help here, or did you mean a toggle
> between:
>   - collect the full hierarchy
>   - read the currently collected data and don't bother with the
>     active kids

No, I meant an operation that syncs up all the child counters to the
parent so that a subsequent read of the counter immediately afterwards
will get a full total (just by reading the parent counter).  But it
could be implemented as a toggle instead.

Paul.