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