Messages in this thread | | | Subject | Re: [patch] Performance Counters for Linux, v4 | From | Andi Kleen <> | Date | Wed, 17 Dec 2008 02:55:10 +0100 |
| |
Paul Mackerras <paulus@samba.org> writes: > > The perf counter subsystem will, in Ingo's design, naturally try to > schedule as many counters and groups on as it can. Given a list of > counters/groups, it could start with the first and keep on trying to > add counters or groups while it can, essentially trying all possible > combinations until it either fills up all the hardware counters or > exhausts the possible combinations. If it moves all the > counters/groups that do fit on up to the head of the list, and then > rotates them to the back of the list when the timeslice expires, that > would probably be OK. In fact the computation about what set of > counters/groups to put on should be done when adding/removing a > counter/group and when the timeslice expires, rather than at context > switch time. (I'm talking about the list of part-time counters/groups > here, of course.)
One issue is that PMU counts can cover more than one CPU. One example for this are the Uncore events on Nehalem (which cover a whole socket) or when you are in AnyThreads monitoring mode (then you get events from both SMT siblings in a core)
With that you would need to examine other CPU's state at context switch time. Probably not a good idea for scalability.
-Andi
-- ak@linux.intel.com
| |