Re: Performance counter API review was [patch] PerformanceCounters for Linux, v3
From: Paul Mackerras
Date: Wed Feb 04 2009 - 05:47:37 EST
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.
--
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/