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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).