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
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,
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
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), )
be
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
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 ultimately
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
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 ideas?).
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
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 struct
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 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
struct
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
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
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
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
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 Wed, Apr 3, 2013 at 7:57 PM, John Stultz john.stu...@linaro.org wrote:
On 04/03/2013 07:22 AM, Stephane Eranian wrote:
On Wed, Apr 3, 2013 at 4:14 PM, David Ahern dsah...@gmail.com wrote:
On 4/3/13 8:00 AM, Stephane Eranian wrote:
Why not have perf convert its
perf_clock timestamps into
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
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 the
On 04/04/2013 01:12 AM, Stephane Eranian wrote:
On Wed, Apr 3, 2013 at 7:57 PM, John Stultz john.stu...@linaro.org 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
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
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
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
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
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
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
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
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
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
On Tue, Apr 2, 2013 at 12:29 AM, David Ahern dsah...@gmail.com 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
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
On Wed, Apr 3, 2013 at 3:55 PM, David Ahern dsah...@gmail.com 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
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
On Wed, Apr 3, 2013 at 4:14 PM, David Ahern dsah...@gmail.com 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
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
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 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 its tightly
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
On 04/03/2013 07:22 AM, Stephane Eranian wrote:
On Wed, Apr 3, 2013 at 4:14 PM, David Ahern dsah...@gmail.com 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
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
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
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
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
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
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 comes
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
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/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
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
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 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 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
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
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 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
>> >>
On Mon, Feb 25, 2013 at 3:10 PM, Peter Zijlstra pet...@infradead.org 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
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 already
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
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/perf time
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
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
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
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
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 that the
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 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
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
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
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
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
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
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() because the
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 in
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
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 going
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
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
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
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(, 0, sizeof(attr));
/* pick a
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 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
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 less
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
On Wed, 2013-02-13 at 20:00 +, Stephane Eranian wrote:
On Wed, Feb 6, 2013 at 7:17 PM, Pawel Moll pawel.m...@arm.com 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
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
On Wed, Feb 6, 2013 at 7:17 PM, Pawel Moll pawel.m...@arm.com 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.
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
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 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 to
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 enough
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),
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
1 - 100 of 130 matches
Mail list logo
