Messages in this thread | | | Date | Wed, 4 Feb 2009 21:47:18 +1100 | From | Paul Mackerras <> | Subject | Re: Performance counter API review was [patch] Performance Counters for Linux, v3 |
| |
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.
| |