From: David Ahern <daahern@cisco.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
mingo@elte.hu, acme@ghostprotocols.net, paulus@samba.org
Subject: Re: [PATCH 2/3] perf events: Introduce realtime clock event
Date: Fri, 18 Feb 2011 07:39:40 -0700 [thread overview]
Message-ID: <4D5E84AC.4040104@cisco.com> (raw)
In-Reply-To: <1298027641.5226.666.camel@laptop>
On 02/18/11 04:14, Peter Zijlstra wrote:
> On Thu, 2011-02-17 at 22:53 -0700, David Ahern wrote:
>> The motivation for this event is to convert perf_clock() time stamps
>> to wall-clock (gettimeofday()) equivalents, including adjustments made
>> by NTP (e.g., for comparing perf events to other log files).
>
>> This patch is based on the monotonic patch by Arnaldo Carvalho de Melo
>> <acme@redhat.com>.
>>
>> (NOTE: Comments from the last review of the timehist patch series
>> suggested calling this a monotonic clock. I am not trying to be
>> dense here; since gettimeofday maps to realtime clock I think that
>> is the better name for it.)
>
> Well, the idea was to use CLOCK_MONOTONIC, not to call CLOCK_REALTIME
> monotonic.
>
> I'm really not sure why you want CLOCK_REALTIME and I think
> CLOCK_MONOTONIC is more useful (I'd argue you want your system logs to
> contain both, every admin who's ever had to untangle what happened
> during DST switches will agree)
I believe CLOCK_MONOTONIC is what perf_clock is tied to -- the
timestamps for PERF_SAMPLE_TIME -- so we already have that.
Programs that generate time-of-day output are using gettimeofday which
is tied to CLOCK_REALTIME. We want to be able to correlate a perf sample
to an entry in an applications log file.
David
>
>> @@ -5610,6 +5612,13 @@ static enum hrtimer_restart perf_swevent_hrtimer(struct hrtimer *hrtimer)
>>
>> perf_sample_data_init(&data, 0);
>> data.period = event->hw.last_period;
>> + if (event->attr.sample_type & PERF_SAMPLE_RAW)
>> + {
>> + raw.size = sizeof(u64);
>> + raw.data = &event->count;
>> + data.raw = &raw;
>> + }
>> +
>> regs = get_irq_regs();
>>
>> if (regs && !perf_exclude_event(event, regs)) {
>
>
> Why!? you already keep ->count = ktime_get_real(), so simply reading the
> count value will get you the timestamp.. this is superfluous at best.
And that is a conundrum I was stuck on for a while. perf record does not
sample counters; it only creates sample events. I looked at having perf
record sample the clock event, but then I would have to synthesize an
event for the output file. Similarly perf record for hardware counters
does not show the value of the counter.
David
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-02-18 14:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 5:53 [PATCH 0/3] perf events: Add realtime clock event and timehist option David Ahern
2011-02-18 5:53 ` [PATCH 1/3] perf events: fix WARN_ON_ONCE for 64-bit raw data, SW events David Ahern
2011-02-18 11:00 ` Peter Zijlstra
2011-02-18 14:33 ` David Ahern
2011-02-18 14:53 ` Arnaldo Carvalho de Melo
2011-02-18 15:01 ` Peter Zijlstra
2011-02-18 17:04 ` Arnaldo Carvalho de Melo
2011-02-18 17:13 ` Peter Zijlstra
2011-02-18 17:15 ` David Ahern
2011-02-18 17:17 ` David Ahern
2011-02-18 14:55 ` Peter Zijlstra
2011-02-18 15:28 ` David Ahern
2011-02-18 15:51 ` Peter Zijlstra
2011-02-18 5:53 ` [PATCH 2/3] perf events: Introduce realtime clock event David Ahern
2011-02-18 11:14 ` Peter Zijlstra
2011-02-18 14:39 ` David Ahern [this message]
2011-02-18 14:58 ` Peter Zijlstra
2011-02-18 15:35 ` David Ahern
2011-02-18 15:39 ` David Ahern
2011-02-20 12:49 ` Ingo Molnar
2011-02-18 5:53 ` [PATCH 3/3] perf events: add timehist option to record and report David Ahern
2011-02-18 7:06 ` Ingo Molnar
2011-02-18 14:28 ` David Ahern
2011-02-18 17:59 ` Frederic Weisbecker
2011-02-18 18:07 ` David Ahern
2011-02-18 18:39 ` Peter Zijlstra
2011-02-18 18:45 ` David Ahern
2011-02-19 9:32 ` Ingo Molnar
2011-02-19 14:38 ` Arnaldo Carvalho de Melo
2011-02-18 19:24 ` Frederic Weisbecker
2011-02-18 19:53 ` David Ahern
2011-02-21 21:13 ` Frederic Weisbecker
2011-02-18 18:41 ` Arnaldo Carvalho de Melo
2011-02-18 18:47 ` David Ahern
2011-02-18 18:53 ` David Ahern
2011-02-18 19:06 ` Arnaldo Carvalho de Melo
2011-02-18 19:29 ` Frederic Weisbecker
2011-02-18 20:30 ` Arnaldo Carvalho de Melo
2011-02-21 21:17 ` Frederic Weisbecker
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=4D5E84AC.4040104@cisco.com \
--to=daahern@cisco.com \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=peterz@infradead.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.