All of lore.kernel.org
 help / color / mirror / Atom feed
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Franck Bui-Huu <vagabon.xyz@gmail.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Francis Moreau <francis.moro@gmail.com>
Subject: Re: perf: some questions about perf software events
Date: Thu, 02 Dec 2010 21:52:18 +0100	[thread overview]
Message-ID: <m3y687rj7h.fsf@gmail.com> (raw)
In-Reply-To: <1291157071.32004.1374.camel@laptop> (Peter Zijlstra's message of "Tue, 30 Nov 2010 23:44:31 +0100")

Peter Zijlstra <a.p.zijlstra@chello.nl> writes:

> On Sat, 2010-11-27 at 14:28 +0100, Franck Bui-Huu wrote:

[...]

>> 
>> 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).
>

But a task can create several instances of the same events, no ?

For HW events, they'll use counters that support the type of these
events and if there are not enough of them then those events will share
the counters in a round robin fashion.

For SW events, there's no limit at all.

So doing:

   attr.type   = PERF_TYPE_SOFTWARE;
   attr.config = PERF_COUNT_SW_ClOCK;
   /* ... */
   tsk_clock_fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
   cpu_clock_fd = sys_perf_event_open(&attr, -1, 0, -1, 0);

should be allowed.

No ?
-- 
		Franck

      reply	other threads:[~2010-12-02 20:52 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
2010-12-02 20:52       ` Franck Bui-Huu [this message]

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=m3y687rj7h.fsf@gmail.com \
    --to=vagabon.xyz@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=francis.moro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.