On Wed, 2013-06-26 at 17:49 +0100, David Ahern wrote:
> With all the perf ioctl extensions tossed out the past day or so I
> wanted to revive this request. Still need a solution to the problem of
> correlating perf_clock to other clocks ...
And I second. We've been trying to squeeze the solution
With all the perf ioctl extensions tossed out the past day or so I
wanted to revive this request. Still need a solution to the problem of
correlating perf_clock to other clocks ...
On 2/1/13 7:18 AM, Pawel Moll wrote:
Hello,
I'd like to revive the topic...
On Tue, 2012-10-16 at 18:23 +0100,
On Mon, Apr 08, 2013 at 12:05:52PM -0700, John Stultz wrote:
>
> So thinking this through further, I'm worried we may _not_ be able
> to eventually enable this to be a vdso as I had earlier hoped.
> Mostly because I'm not sure how the fd -> file -> clock lookup could
> be done in userland (any ide
On 04/08/2013 10:58 AM, Pawel Moll wrote:
Now, before I spend time doing all this, a question to John, Peter,
Stephane and the rest of the public - would a solution providing such
userspace interface:
fd = sys_perf_open()
timestamp = clock_gettime((FD_TO_CLOCKID(fd), &ts)
be acc
On Sat, 2013-04-06 at 12:05 +0100, Richard Cochran wrote:
> On Fri, Apr 05, 2013 at 07:16:53PM +0100, Pawel Moll wrote:
> > Ok, so how about the code below? Disclaimer: this is just a proposal.
> > I'm not sure how welcomed would be an extra field in struct file, but
> > this makes the clocks ultim
On Fri, Apr 05, 2013 at 07:16:53PM +0100, Pawel Moll wrote:
> Ok, so how about the code below? Disclaimer: this is just a proposal.
> I'm not sure how welcomed would be an extra field in struct file, but
> this makes the clocks ultimately flexible - one can "attach" the clock
> to any arbitrary s
On Thu, 2013-04-04 at 17:29 +0100, Pawel Moll wrote:
> > Maybe can we extend the dynamic posix clock code to work on more then
> > just the chardev?
>
> The idea I'm following now is to make the dynamic clock framework even
> more generic, so there could be a clock associated with an arbitrary
>
On 04/04/2013 01:12 AM, Stephane Eranian wrote:
On Wed, Apr 3, 2013 at 7:57 PM, John Stultz wrote:
I'm not sure I follow this. If perf exported data came with CLOCK_MONOTONIC
timestamps, no correlation would need to be exposed. perf would just have
to do the extra overhead of doing the convers
On Thu, 2013-04-04 at 08:37 +0100, Richard Cochran wrote:
> > I get the reasoning around reusing the fd we already have, but is
> > the possibility of a dynamic chardev pathname really a big concern?
>
> I have been following this thread, and, not knowing very much about
> perf, I would think that
On Wed, 2013-04-03 at 18:50 +0100, John Stultz wrote:
> I get the reasoning around reusing the fd we already have, but is the
> possibility of a dynamic chardev pathname really a big concern?
Well, in my particular development system I have no udev, so I had to
manually do "mknod". Perf syscall w
On Wed, Apr 3, 2013 at 7:57 PM, John Stultz wrote:
> On 04/03/2013 07:22 AM, Stephane Eranian wrote:
>>
>> On Wed, Apr 3, 2013 at 4:14 PM, David Ahern wrote:
>>>
>>> On 4/3/13 8:00 AM, Stephane Eranian wrote:
>
> Why not have perf convert its
> perf_clock timestamps into monotonic or
On Wed, Apr 03, 2013 at 10:50:57AM -0700, John Stultz wrote:
>
> I get the reasoning around reusing the fd we already have, but is
> the possibility of a dynamic chardev pathname really a big concern?
I have been following this thread, and, not knowing very much about
perf, I would think that the
On 04/03/2013 07:22 AM, Stephane Eranian wrote:
On Wed, Apr 3, 2013 at 4:14 PM, David Ahern wrote:
On 4/3/13 8:00 AM, Stephane Eranian wrote:
Why not have perf convert its
perf_clock timestamps into monotonic or realtime when dumping events?
So this is exactly what I've been wondering throug
On 04/03/2013 10:35 AM, Pawel Moll wrote:
On Wed, 2013-04-03 at 18:29 +0100, John Stultz wrote:
On 04/03/2013 10:19 AM, Pawel Moll wrote:
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
But if we're going to have to do
this via a clockid, I'm going to want it to be done via a dynamic pos
On Wed, 2013-04-03 at 18:29 +0100, John Stultz wrote:
> On 04/03/2013 10:19 AM, Pawel Moll wrote:
> > On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> >> But if we're going to have to do
> >> this via a clockid, I'm going to want it to be done via a dynamic posix
> >> clockid, so its clear i
On 04/03/2013 10:19 AM, Pawel Moll wrote:
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
But if we're going to have to do
this via a clockid, I'm going to want it to be done via a dynamic posix
clockid, so its clear its tightly tied with perf and not considered a
generic interface (and I
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> But if we're going to have to do
> this via a clockid, I'm going to want it to be done via a dynamic posix
> clockid, so its clear its tightly tied with perf and not considered a
> generic interface (and I can clearly point folks having pro
On Wed, Apr 3, 2013 at 4:14 PM, David Ahern wrote:
> On 4/3/13 8:00 AM, Stephane Eranian wrote:
>>>
>>> What's the advantage of changing apps -- like the JIT compiler -- to emit
>>> perf based timestamps versus having perf emit existing timestamps? ie.,
>>> monotonic and realtime clocks already ha
On 4/3/13 8:00 AM, Stephane Eranian wrote:
What's the advantage of changing apps -- like the JIT compiler -- to emit
perf based timestamps versus having perf emit existing timestamps? ie.,
monotonic and realtime clocks already have vdso mappings for userspace with
well known performance character
On Wed, Apr 3, 2013 at 3:55 PM, David Ahern wrote:
> On 4/3/13 3:17 AM, Stephane Eranian wrote:
>>
>> I haven't done any specific testing with either approach yet. The goal is
>> to
>> use this perf timestamp to correlate user level events to hardware
>> events recorded
>> by the kernel. I would a
On 4/3/13 3:17 AM, Stephane Eranian wrote:
I haven't done any specific testing with either approach yet. The goal is to
use this perf timestamp to correlate user level events to hardware
events recorded
by the kernel. I would assume there would be situations where those user events
could be on th
On Tue, Apr 2, 2013 at 12:29 AM, David Ahern wrote:
> On 4/1/13 12:29 PM, John Stultz wrote:
>>>
>>> Any chance a decision can be reached in time for 3.10? Seems like the
>>> simplest option is the perf event based ioctl.
>>
>>
>> I'm still not sold on the CLOCK_PERF posix clock. The semantics are
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> I still think exposing the perf clock to userland is a bad idea, and
> would much rather the kernel provide timestamp data in the logs
> themselves to make the logs useful. But if we're going to have to do
> this via a clockid, I'm going to
On 04/02/2013 12:54 AM, Peter Zijlstra wrote:
On Mon, 2013-04-01 at 11:29 -0700, John Stultz wrote:
I'm still not sold on the CLOCK_PERF posix clock. The semantics are
still too hand-wavy and implementation specific.
How about we define the semantics as: match whatever comes out of perf
(and pr
On Tue, 2013-04-02 at 08:54 +0100, Peter Zijlstra wrote:
> On Mon, 2013-04-01 at 11:29 -0700, John Stultz wrote:
> > I'm still not sold on the CLOCK_PERF posix clock. The semantics are
> > still too hand-wavy and implementation specific.
>
> How about we define the semantics as: match whatever co
On Mon, 2013-04-01 at 11:29 -0700, John Stultz wrote:
> I'm still not sold on the CLOCK_PERF posix clock. The semantics are
> still too hand-wavy and implementation specific.
How about we define the semantics as: match whatever comes out of perf
(and preferably ftrace by default) stuff?
Since th
On 04/01/2013 03:29 PM, David Ahern wrote:
On 4/1/13 12:29 PM, John Stultz wrote:
Any chance a decision can be reached in time for 3.10? Seems like the
simplest option is the perf event based ioctl.
I'm still not sold on the CLOCK_PERF posix clock. The semantics are
still too hand-wavy and imp
On 4/1/13 12:29 PM, John Stultz wrote:
Any chance a decision can be reached in time for 3.10? Seems like the
simplest option is the perf event based ioctl.
I'm still not sold on the CLOCK_PERF posix clock. The semantics are
still too hand-wavy and implementation specific.
While I'd prefer perf
On 03/31/2013 09:23 AM, David Ahern wrote:
On 3/14/13 1:57 PM, Pawel Moll wrote:
Ok, how about the code below? I must say I have some doubts about the
resolution, as there seem to be no generic way of figuring it out for
the sched_clock (the arch/arm/kernel/sched_clock.c is actually
calculating
On 3/14/13 1:57 PM, Pawel Moll wrote:
Ok, how about the code below? I must say I have some doubts about the
resolution, as there seem to be no generic way of figuring it out for
the sched_clock (the arch/arm/kernel/sched_clock.c is actually
calculating it, but than just prints it out and nothing
On Thu, 2013-03-14 at 15:34 +, Stephane Eranian wrote:
> > Well, the timestamps themselves are already exposed to userspace
> > through the ftrace and perf data logs. All people want is to add
> > secondary data stream in the same time-line.
> >
> I agree with Peter on this. The timestamps are
On Mon, Feb 25, 2013 at 3:10 PM, Peter Zijlstra wrote:
> On Fri, 2013-02-22 at 22:04 -0800, John Stultz wrote:
>> On 02/20/2013 02:29 AM, Peter Zijlstra wrote:
>> > On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote:
>> >> So describe how the perf time domain is different then
>> >> CLOCK_MONOTO
On Fri, 2013-02-22 at 22:04 -0800, John Stultz wrote:
> On 02/20/2013 02:29 AM, Peter Zijlstra wrote:
> > On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote:
> >> So describe how the perf time domain is different then
> >> CLOCK_MONOTONIC_RAW.
> > The primary difference is that the trace/sched/pe
On 02/20/2013 02:29 AM, Peter Zijlstra wrote:
On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote:
So describe how the perf time domain is different then
CLOCK_MONOTONIC_RAW.
The primary difference is that the trace/sched/perf time domain is not
strictly monotonic, it is only locally monotonic
On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote:
> So describe how the perf time domain is different then
> CLOCK_MONOTONIC_RAW.
The primary difference is that the trace/sched/perf time domain is not
strictly monotonic, it is only locally monotonic -- that is two time
stamps taken on the same
On Tue, 19 Feb 2013, John Stultz wrote:
> On 02/19/2013 01:50 PM, Thomas Gleixner wrote:
> > 2) Doing #1 will allow to observe the described time going backwards
> > scenario in kernel as well.
> >
> > The reason why we did not get complaints about that scenario at all
> > (yet) is tha
On 02/19/2013 01:50 PM, Thomas Gleixner wrote:
On Tue, 19 Feb 2013, John Stultz wrote:
On 02/19/2013 12:15 PM, Thomas Gleixner wrote:
Depending on the length of the delay which kept VCPU0 away from
executing and depending on the direction of the ntp update of the
timekeeping variables __vdso_cl
On Tue, 19 Feb 2013, John Stultz wrote:
> On 02/19/2013 12:15 PM, Thomas Gleixner wrote:
> > Depending on the length of the delay which kept VCPU0 away from
> > executing and depending on the direction of the ntp update of the
> > timekeeping variables __vdso_clock_gettime()#2 can observe time goin
On 02/19/2013 12:15 PM, Thomas Gleixner wrote:
On Tue, 19 Feb 2013, Thomas Gleixner wrote:
On Tue, 19 Feb 2013, John Stultz wrote:
Would be interesting to compare and contrast that. Though you can't do
that in the kernel as the write hold time of the timekeeper seq is way
larger than the gtod->s
On Tue, 19 Feb 2013, Thomas Gleixner wrote:
> On Tue, 19 Feb 2013, John Stultz wrote:
> Would be interesting to compare and contrast that. Though you can't do
> that in the kernel as the write hold time of the timekeeper seq is way
> larger than the gtod->seq write hold time. I have a patch series
On Tue, 19 Feb 2013, John Stultz wrote:
> On 02/18/2013 12:35 PM, Thomas Gleixner wrote:
> > On Tue, 5 Feb 2013, John Stultz wrote:
> > > On 02/05/2013 02:13 PM, Stephane Eranian wrote:
> > > > But if people are strongly opposed to the clock_gettime() approach, then
> > > > I can go with the ioctl(
On 02/18/2013 12:35 PM, Thomas Gleixner wrote:
On Tue, 5 Feb 2013, John Stultz wrote:
On 02/05/2013 02:13 PM, Stephane Eranian wrote:
But if people are strongly opposed to the clock_gettime() approach, then
I can go with the ioctl() because the functionality is definitively needed
ASAP.
I pref
On Tue, 5 Feb 2013, John Stultz wrote:
> On 02/05/2013 02:13 PM, Stephane Eranian wrote:
> > But if people are strongly opposed to the clock_gettime() approach, then
> > I can go with the ioctl() because the functionality is definitively needed
> > ASAP.
>
> I prefer the ioctl method, since its le
On 2/18/13 8:16 AM, Stephane Eranian wrote:
Hi,
I think the advantage of the ioctl() is that is reuses existing infrastructure.
The downside is that to get the timestamp you need at a minimum:
uint64_t get_perf_timestamp(void)
{
struct perf_event_attr attr;
uint64_t ts = 0;
int fd;
Hi,
I think the advantage of the ioctl() is that is reuses existing infrastructure.
The downside is that to get the timestamp you need at a minimum:
uint64_t get_perf_timestamp(void)
{
struct perf_event_attr attr;
uint64_t ts = 0;
int fd;
memset(&attr, 0, sizeof(attr));
/* pick
On Wed, 2013-02-13 at 20:00 +, Stephane Eranian wrote:
> On Wed, Feb 6, 2013 at 7:17 PM, Pawel Moll wrote:
> > On Wed, 2013-02-06 at 01:19 +, Steven Rostedt wrote:
> >> If people are worried about adding a bunch of new perf syscalls, maybe
> >> add a sys_perf_control() system call that wor
On Wed, Feb 6, 2013 at 7:17 PM, Pawel Moll wrote:
> On Wed, 2013-02-06 at 01:19 +, Steven Rostedt wrote:
>> If people are worried about adding a bunch of new perf syscalls, maybe
>> add a sys_perf_control() system call that works like an ioctl but
>> without a file descriptor. Something for th
On Tue, 2013-02-05 at 22:13 +, Stephane Eranian wrote:
> The app requesting the timestamp may not necessarily have an active
> perf session. And by that I mean, it may not be self-monitoring. But it
> could be monitored by an external tool such as perf, without necessary
> knowing it.
Fair eno
On Wed, 2013-02-06 at 01:19 +, Steven Rostedt wrote:
> If people are worried about adding a bunch of new perf syscalls, maybe
> add a sys_perf_control() system call that works like an ioctl but
> without a file descriptor. Something for things that don't require an
> event attached to it, like
On Tue, 2013-02-05 at 14:28 -0800, John Stultz wrote:
> I prefer the ioctl method, since its less likely to be re-purposed/misused.
>
> Though I'd be most comfortable with finding some way for perf-timestamps
> to be CLOCK_MONOTONIC based (or maybe CLOCK_MONOTONIC_RAW if it would be
> easier), a
On 02/05/2013 02:13 PM, Stephane Eranian wrote:
On Fri, Feb 1, 2013 at 3:18 PM, Pawel Moll wrote:
Hello,
I'd like to revive the topic...
On Tue, 2012-10-16 at 18:23 +0100, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
Hi,
There are many situations where w
On Fri, Feb 1, 2013 at 3:18 PM, Pawel Moll wrote:
> Hello,
>
> I'd like to revive the topic...
>
> On Tue, 2012-10-16 at 18:23 +0100, Peter Zijlstra wrote:
>> On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
>> > Hi,
>> >
>> > There are many situations where we want to correlate events h
On 2/1/13 7:18 AM, Pawel Moll wrote:
8<---
From 2ad51a27fbf64bf98cee190efc3fbd7002819692 Mon Sep 17 00:00:00 2001
From: Pawel Moll
Date: Fri, 1 Feb 2013 14:03:56 +
Subject: [PATCH] perf: Add ioctl to return current time value
To co-relate user space events with the perf events stream
a cur
Hello,
I'd like to revive the topic...
On Tue, 2012-10-16 at 18:23 +0100, Peter Zijlstra wrote:
> On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
> > Hi,
> >
> > There are many situations where we want to correlate events happening at
> > the user level with samples recorded in the pe
On Wed, 2012-11-14 at 14:26 -0800, John Stultz wrote:
> > There's also trace_clock_counter() which isn't even a clock :-) It's
> > just a incremental atomic counter that goes up every time it's called.
> > This is the most synced clock, but is absolutely meaningless for
> > timestamps. It's just
On 11/13/2012 12:58 PM, Steven Rostedt wrote:
On Fri, 2012-11-09 at 18:04 -0800, John Stultz wrote:
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
I've no problem with adding CLOCK_PERF (or another/better name).
Hrm. I'm not excited about exporting that sort of internal kernel
details to userla
On Fri, 2012-11-09 at 18:04 -0800, John Stultz wrote:
> On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
> > I've no problem with adding CLOCK_PERF (or another/better name).
> Hrm. I'm not excited about exporting that sort of internal kernel
> details to userland.
>
> The behavior and expectations
On 11/12/2012 12:54 PM, Stephane Eranian wrote:
On Mon, Nov 12, 2012 at 7:53 PM, John Stultz wrote:
On 11/11/2012 12:32 PM, Stephane Eranian wrote:
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz
wrote:
Also I worry that it will be abused in the same way that direct TSC
access
is, where the see
On Mon, Nov 12, 2012 at 7:53 PM, John Stultz wrote:
> On 11/11/2012 12:32 PM, Stephane Eranian wrote:
>>
>> On Sat, Nov 10, 2012 at 3:04 AM, John Stultz
>> wrote:
>>>
>>> On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
>
>
On 11/11/2012 12:32 PM, Stephane Eranian wrote:
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz wrote:
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
Hi,
There are many situations where we want to correlate events happening at
the user l
On Sat, Nov 10, 2012 at 3:04 AM, John Stultz wrote:
> On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
>>
>> On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
>>>
>>> Hi,
>>>
>>> There are many situations where we want to correlate events happening at
>>> the user level with samples recorded
On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
Hi,
There are many situations where we want to correlate events happening at
the user level with samples recorded in the perf_event kernel sampling buffer.
For instance, we might want to cor
On Tue, Oct 16, 2012 at 7:23 PM, Peter Zijlstra wrote:
> On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
>> Hi,
>>
>> There are many situations where we want to correlate events happening at
>> the user level with samples recorded in the perf_event kernel sampling
>> buffer.
>> For ins
On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
> Hi,
>
> There are many situations where we want to correlate events happening at
> the user level with samples recorded in the perf_event kernel sampling buffer.
> For instance, we might want to correlate the call to a function or creati
Hi,
There are many situations where we want to correlate events happening at
the user level with samples recorded in the perf_event kernel sampling buffer.
For instance, we might want to correlate the call to a function or creation of
a file with samples. Similarly, when we want to monitor a JVM w
65 matches
Mail list logo
