From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Francis Moreau <francis.moro@gmail.com>
Subject: Re: perf: some questions about perf software events
Date: Tue, 30 Nov 2010 23:44:31 +0100 [thread overview]
Message-ID: <1291157071.32004.1374.camel@laptop> (raw)
In-Reply-To: <m3oc9a520m.fsf@gmail.com>
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).
next prev parent reply other threads:[~2010-11-30 22:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 11:35 perf: some questions about perf software events Franck Bui-Huu
2010-11-24 11:41 ` Peter Zijlstra
2010-11-27 13:28 ` Franck Bui-Huu
2010-11-30 22:44 ` Peter Zijlstra [this message]
2010-12-02 20:52 ` Franck Bui-Huu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1291157071.32004.1374.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=francis.moro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vagabon.xyz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.