Messages in this thread | | | Subject | Re: perf: some questions about perf software events | From | Peter Zijlstra <> | Date | Tue, 30 Nov 2010 23:44:31 +0100 |
| |
On Sat, 2010-11-27 at 14:28 +0100, Franck Bui-Huu wrote: > Peter Zijlstra <a.p.zijlstra@chello.nl> writes: > > > On Wed, 2010-11-24 at 12:35 +0100, Franck Bui-Huu wrote: > > [...] > > >> That is for no 'contiguous' events, setting a sampling frequency doesn't > >> really make sense since for example you could set a frequency to 1000 HZ > >> for the software ALIGNMENT_FAULT event and never get any samplings or at > >> least getting sampling but with a totally different rate. And the > >> current code doesn't look to handle sample_freq anyway. > > > > All the freq bits are in the generic code, it re-computes the rate on > > the timer-tick as well as on each event occurrence. > > > > Freq driven sampling should work just fine with swevents. > > > > Yes, but how does it behave with ALIGNMENT_FAULTS for example ? > > Such event may happen at a very disparate rate or it can even never > happen at all.
Then of course we'll never make the freq target, again, software events aren't special there.
> > > >> Also I'm currently not seeing any real differences between cpu-clock and > >> task-clock events. They both seem to count the time elapsed when the > >> task is running on a CPU. Am I wrong ? > > > > No, Francis already noticed that, I probably wrecked it when I added the > > multi-pmu stuff, its on my todo list to look at (Francis also handed me > > a little patchlet), but I keep getting distracted with other stuff :/ > > OK. > > Does it make sense to adjust the period for both of them ? > > Also, when creating a task clock event, passing 'pid=-1' to > sys_perf_event_open() doesn't really make sense, does it ? > > Same with cpu clock and 'pid=n': whatever <n> value, the event measure > the cpu wall time clock. > > Perhaps proposing only one clock in the API and internally bind this > clock to the cpu or task clock depending on pid or cpu parameters would > have been better ? >
No, it actually makes sense to count both cpu and task clock on a task (cpu clock basically being wall-time).
| |