Expose the NMI safe accessor to the monotonic raw clock to the
tracer. The mono clock was added with commit
1b3e5c0936046e7e023149ddc8946d21c2ea20eb. Although the monotonic raw
clock cannot be used to compare time between different machines, it is
not perterbed by ntp.
Signed-off-by: Drew Richardson <[email protected]>
---
kernel/trace/trace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 05330494a0df..458031c31a37 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -876,6 +876,7 @@ static struct {
{ trace_clock_jiffies, "uptime", 0 },
{ trace_clock, "perf", 1 },
{ ktime_get_mono_fast_ns, "mono", 1 },
+ { ktime_get_raw_fast_ns, "mono_raw", 1 },
ARCH_TRACE_CLOCKS
};
--
2.1.4
----- Original Message -----
> Expose the NMI safe accessor to the monotonic raw clock to the
> tracer. The mono clock was added with commit
> 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. Although the monotonic raw
> clock cannot be used to compare time between different machines, it is
> not perterbed by ntp.
perterbed -> perturbed
>
> Signed-off-by: Drew Richardson <[email protected]>
>
What is the use-case that justify exposing the "raw fast"
clock that cannot be handled by the "monotonic fast" clock ?
Thanks,
Mathieu
> ---
> kernel/trace/trace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 05330494a0df..458031c31a37 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -876,6 +876,7 @@ static struct {
> { trace_clock_jiffies, "uptime", 0 },
> { trace_clock, "perf", 1 },
> { ktime_get_mono_fast_ns, "mono", 1 },
> + { ktime_get_raw_fast_ns, "mono_raw", 1 },
> ARCH_TRACE_CLOCKS
> };
>
> --
> 2.1.4
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
On Mon, May 04, 2015 at 04:10:05PM +0100, Mathieu Desnoyers wrote:
> ----- Original Message -----
> > Expose the NMI safe accessor to the monotonic raw clock to the
> > tracer. The mono clock was added with commit
> > 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. Although the monotonic raw
> > clock cannot be used to compare time between different machines, it is
> > not perterbed by ntp.
>
> perterbed -> perturbed
Oops, I'll correct that in the next version.
> >
> > Signed-off-by: Drew Richardson <[email protected]>
> >
>
> What is the use-case that justify exposing the "raw fast"
> clock that cannot be handled by the "monotonic fast" clock ?
>
> Thanks,
>
> Mathieu
I'm collecting and merging data from perf, with Android Atrace data
(writes to /sys/kernel/debug/tracing/trace_marker) which ends up in
the ftrace stream and other measurements collected from
userspace. Currently the only clock readable from userspace, supported
by perf and by ftrace is CLOCK_MONOTONIC. However this clock is
affected by the incremental adjustments performed by adjtime(3) and
NTP. But I'd prefer to use a clock that is advancing at a consistent
rate, hence CLOCK_MONOTONIC_RAW.
Thanks,
Drew
> > ---
> > kernel/trace/trace.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 05330494a0df..458031c31a37 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -876,6 +876,7 @@ static struct {
> > { trace_clock_jiffies, "uptime", 0 },
> > { trace_clock, "perf", 1 },
> > { ktime_get_mono_fast_ns, "mono", 1 },
> > + { ktime_get_raw_fast_ns, "mono_raw", 1 },
> > ARCH_TRACE_CLOCKS
> > };
> >
> > --
> > 2.1.4
> >
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
On Mon, May 4, 2015 at 1:05 PM, Drew Richardson <[email protected]> wrote:
> On Mon, May 04, 2015 at 04:10:05PM +0100, Mathieu Desnoyers wrote:
>> ----- Original Message -----
>> > Expose the NMI safe accessor to the monotonic raw clock to the
>> > tracer. The mono clock was added with commit
>> > 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. Although the monotonic raw
>> > clock cannot be used to compare time between different machines, it is
>> > not perterbed by ntp.
>>
>> perterbed -> perturbed
>
> Oops, I'll correct that in the next version.
>
>> >
>> > Signed-off-by: Drew Richardson <[email protected]>
>> >
>>
>> What is the use-case that justify exposing the "raw fast"
>> clock that cannot be handled by the "monotonic fast" clock ?
>>
>> Thanks,
>>
>> Mathieu
>
> I'm collecting and merging data from perf, with Android Atrace data
> (writes to /sys/kernel/debug/tracing/trace_marker) which ends up in
> the ftrace stream and other measurements collected from
> userspace. Currently the only clock readable from userspace, supported
> by perf and by ftrace is CLOCK_MONOTONIC. However this clock is
> affected by the incremental adjustments performed by adjtime(3) and
> NTP. But I'd prefer to use a clock that is advancing at a consistent
> rate, hence CLOCK_MONOTONIC_RAW.
Well, I'd caution against assuming CLOCK_MONOTONIC_RAW is really a
consistent rate, since w/ thermal changes the oscillator likely will
drift around. But especially during early initialization, ntp can
manipulate the CLOCK_MONOTONIC freq more drastically to align time.
Another more concrete benefit is that since CLOCK_MONOTONIC is
frequency adjusted, its possible for slight inconsistencies to appear
when using the lock-free ktime_get_mono_fast_ns() accessor that perf
uses. With CLOCK_MONOTONIC_RAW, since there are no frequency
adjustments made, inconsistencies shouldn't occur with the lock-free
accessor.
thanks
-john
On Mon, May 04, 2015 at 01:05:19PM -0700, Drew Richardson wrote:
> I'm collecting and merging data from perf, with Android Atrace data
> (writes to /sys/kernel/debug/tracing/trace_marker) which ends up in
> the ftrace stream and other measurements collected from
> userspace. Currently the only clock readable from userspace, supported
> by perf and by ftrace is CLOCK_MONOTONIC. However this clock is
> affected by the incremental adjustments performed by adjtime(3) and
> NTP.
Which should not matter at all, right? If both sources are using the
same clock (they are) then its trivial to merge them and everything
works as expected.
> But I'd prefer to use a clock that is advancing at a consistent
> rate, hence CLOCK_MONOTONIC_RAW.
Right, Mathieu is asking _why_ you prefer that?
On Mon, May 04, 2015 at 09:57:48PM +0100, Peter Zijlstra wrote:
> On Mon, May 04, 2015 at 01:05:19PM -0700, Drew Richardson wrote:
> > I'm collecting and merging data from perf, with Android Atrace data
> > (writes to /sys/kernel/debug/tracing/trace_marker) which ends up in
> > the ftrace stream and other measurements collected from
> > userspace. Currently the only clock readable from userspace, supported
> > by perf and by ftrace is CLOCK_MONOTONIC. However this clock is
> > affected by the incremental adjustments performed by adjtime(3) and
> > NTP.
>
> Which should not matter at all, right? If both sources are using the
> same clock (they are) then its trivial to merge them and everything
> works as expected.
>
> > But I'd prefer to use a clock that is advancing at a consistent
> > rate, hence CLOCK_MONOTONIC_RAW.
>
> Right, Mathieu is asking _why_ you prefer that?
>
I think John described it well.
On Mon, May 04, 2015 at 09:47:57PM +0100, John Stultz wrote:
> ... [D]uring early initialization, ntp can
> manipulate the CLOCK_MONOTONIC freq more drastically to align time.
>
> Another more concrete benefit is that since CLOCK_MONOTONIC is
> frequency adjusted, its possible for slight inconsistencies to appear
> when using the lock-free ktime_get_mono_fast_ns() accessor that perf
> uses. With CLOCK_MONOTONIC_RAW, since there are no frequency
> adjustments made, inconsistencies shouldn't occur with the lock-free
> accessor.
>
CLOCK_MONOTONIC_RAW will advance more constantly than CLOCK_MONOTONIC.
Imagine someone is trying to optimize a particular program to reduce
instructions executed for a given workload while minimizing the effect
on runtime. Also suppose that ntp is running and potentially making
larger adjustments to CLOCK_MONOTONIC. If ntp is adjusting
CLOCK_MONOTONIC to advance more rapidly, the program will appear to
use fewer instructions per second but run longer than it would if
CLOCK_MONOTONIC_RAW had been used. The total number of instructions
observed would be the same regardless of the clock source used, but
how it's attributed to time would be affected.
Conversely if ntp is adjusting CLOCK_MONOTONIC to advance more slowly,
the program will appear to use more instructions per second but run
more quickly. Of course there are many sources that can cause jitter
in performance measurements on modern processors, but I'd like to
remove ntp from the list.
Thanks,
Drew
On Tue, 5 May 2015 07:54:46 -0700
Drew Richardson <[email protected]> wrote:
> CLOCK_MONOTONIC_RAW will advance more constantly than CLOCK_MONOTONIC.
>
> Imagine someone is trying to optimize a particular program to reduce
> instructions executed for a given workload while minimizing the effect
> on runtime. Also suppose that ntp is running and potentially making
> larger adjustments to CLOCK_MONOTONIC. If ntp is adjusting
> CLOCK_MONOTONIC to advance more rapidly, the program will appear to
> use fewer instructions per second but run longer than it would if
> CLOCK_MONOTONIC_RAW had been used. The total number of instructions
> observed would be the same regardless of the clock source used, but
> how it's attributed to time would be affected.
>
> Conversely if ntp is adjusting CLOCK_MONOTONIC to advance more slowly,
> the program will appear to use more instructions per second but run
> more quickly. Of course there are many sources that can cause jitter
> in performance measurements on modern processors, but I'd like to
> remove ntp from the list.
What's the consensus on this patch? Everyone OK with it? If so, can you
please post a new patch with the proper change log. And can everyone
else give acks. I can take it in my tree.
Thanks,
-- Steve
----- Original Message -----
> On Tue, 5 May 2015 07:54:46 -0700
> Drew Richardson <[email protected]> wrote:
>
> > CLOCK_MONOTONIC_RAW will advance more constantly than CLOCK_MONOTONIC.
> >
> > Imagine someone is trying to optimize a particular program to reduce
> > instructions executed for a given workload while minimizing the effect
> > on runtime. Also suppose that ntp is running and potentially making
> > larger adjustments to CLOCK_MONOTONIC. If ntp is adjusting
> > CLOCK_MONOTONIC to advance more rapidly, the program will appear to
> > use fewer instructions per second but run longer than it would if
> > CLOCK_MONOTONIC_RAW had been used. The total number of instructions
> > observed would be the same regardless of the clock source used, but
> > how it's attributed to time would be affected.
> >
> > Conversely if ntp is adjusting CLOCK_MONOTONIC to advance more slowly,
> > the program will appear to use more instructions per second but run
> > more quickly. Of course there are many sources that can cause jitter
> > in performance measurements on modern processors, but I'd like to
> > remove ntp from the list.
>
> What's the consensus on this patch? Everyone OK with it? If so, can you
> please post a new patch with the proper change log. And can everyone
> else give acks. I can take it in my tree.
I can see it being useful for tracing early boot, e.g.
when debugging issues with NTP. So adding it to ftrace
makes sense to me.
Acked-by: Mathieu Desnoyers <[email protected]>
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
On Tue, 5 May 2015 07:54:46 -0700
Drew Richardson <[email protected]> wrote:
> CLOCK_MONOTONIC_RAW will advance more constantly than CLOCK_MONOTONIC.
>
> Imagine someone is trying to optimize a particular program to reduce
> instructions executed for a given workload while minimizing the effect
> on runtime. Also suppose that ntp is running and potentially making
> larger adjustments to CLOCK_MONOTONIC. If ntp is adjusting
> CLOCK_MONOTONIC to advance more rapidly, the program will appear to
> use fewer instructions per second but run longer than it would if
> CLOCK_MONOTONIC_RAW had been used. The total number of instructions
> observed would be the same regardless of the clock source used, but
> how it's attributed to time would be affected.
>
> Conversely if ntp is adjusting CLOCK_MONOTONIC to advance more slowly,
> the program will appear to use more instructions per second but run
> more quickly. Of course there are many sources that can cause jitter
> in performance measurements on modern processors, but I'd like to
> remove ntp from the list.
This is a nice description, and was expecting to see it in the change
log of the latest patch. Can you resend with a more detailed
description (like the above).
Thanks!
-- Steve
On Fri, May 08, 2015 at 03:09:03PM +0100, Steven Rostedt wrote:
> On Tue, 5 May 2015 07:54:46 -0700
> Drew Richardson <[email protected]> wrote:
>
> > CLOCK_MONOTONIC_RAW will advance more constantly than CLOCK_MONOTONIC.
> >
> > Imagine someone is trying to optimize a particular program to reduce
> > instructions executed for a given workload while minimizing the effect
> > on runtime. Also suppose that ntp is running and potentially making
> > larger adjustments to CLOCK_MONOTONIC. If ntp is adjusting
> > CLOCK_MONOTONIC to advance more rapidly, the program will appear to
> > use fewer instructions per second but run longer than it would if
> > CLOCK_MONOTONIC_RAW had been used. The total number of instructions
> > observed would be the same regardless of the clock source used, but
> > how it's attributed to time would be affected.
> >
> > Conversely if ntp is adjusting CLOCK_MONOTONIC to advance more slowly,
> > the program will appear to use more instructions per second but run
> > more quickly. Of course there are many sources that can cause jitter
> > in performance measurements on modern processors, but I'd like to
> > remove ntp from the list.
>
> This is a nice description, and was expecting to see it in the change
> log of the latest patch. Can you resend with a more detailed
> description (like the above).
>
> Thanks!
>
> -- Steve
>
Sorry about that, thanks for your patience.
Expose the NMI safe accessor to the monotonic raw clock to the
tracer. The mono clock was added with commit
1b3e5c0936046e7e023149ddc8946d21c2ea20eb. The advantage of the
monotonic raw clock is that it will advance more constantly than the
monotonic clock.
Imagine someone is trying to optimize a particular program to reduce
instructions executed for a given workload while minimizing the effect
on runtime. Also suppose that NTP is running and potentially making
larger adjustments to the monotonic clock. If NTP is adjusting the
monotonic clock to advance more rapidly, the program will appear to
use fewer instructions per second but run longer than if the monotonic
raw clock had been used. The total number of instructions observed
would be the same regardless of the clock source used, but how it's
attributed to time would be affected.
Conversely if NTP is adjusting the monotonic clock to advance more
slowly, the program will appear to use more instructions per second
but run more quickly. Of course there are many sources that can cause
jitter in performance measurements on modern processors, but let's
remove NTP from the list.
The monotonic raw clock can also be useful for tracing early boot,
e.g. when debugging issues with NTP.
Signed-off-by: Drew Richardson <[email protected]>
Acked-by: Mathieu Desnoyers <[email protected]>
---
kernel/trace/trace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 05330494a0df..458031c31a37 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -876,6 +876,7 @@ static struct {
{ trace_clock_jiffies, "uptime", 0 },
{ trace_clock, "perf", 1 },
{ ktime_get_mono_fast_ns, "mono", 1 },
+ { ktime_get_raw_fast_ns, "mono_raw", 1 },
ARCH_TRACE_CLOCKS
};
--
2.1.4
On Fri, 8 May 2015 07:30:39 -0700
Drew Richardson <[email protected]> wrote:
> Expose the NMI safe accessor to the monotonic raw clock to the
> tracer. The mono clock was added with commit
> 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. The advantage of the
> monotonic raw clock is that it will advance more constantly than the
> monotonic clock.
>
> Imagine someone is trying to optimize a particular program to reduce
> instructions executed for a given workload while minimizing the effect
> on runtime. Also suppose that NTP is running and potentially making
> larger adjustments to the monotonic clock. If NTP is adjusting the
> monotonic clock to advance more rapidly, the program will appear to
> use fewer instructions per second but run longer than if the monotonic
> raw clock had been used. The total number of instructions observed
> would be the same regardless of the clock source used, but how it's
> attributed to time would be affected.
>
> Conversely if NTP is adjusting the monotonic clock to advance more
> slowly, the program will appear to use more instructions per second
> but run more quickly. Of course there are many sources that can cause
> jitter in performance measurements on modern processors, but let's
> remove NTP from the list.
>
> The monotonic raw clock can also be useful for tracing early boot,
> e.g. when debugging issues with NTP.
>
Peter, Thomas, John, you OK with this?
-- Steve
> Signed-off-by: Drew Richardson <[email protected]>
> Acked-by: Mathieu Desnoyers <[email protected]>
> ---
> kernel/trace/trace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 05330494a0df..458031c31a37 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -876,6 +876,7 @@ static struct {
> { trace_clock_jiffies, "uptime", 0 },
> { trace_clock, "perf", 1 },
> { ktime_get_mono_fast_ns, "mono", 1 },
> + { ktime_get_raw_fast_ns, "mono_raw", 1 },
> ARCH_TRACE_CLOCKS
> };
>
On Fri, May 8, 2015 at 7:41 AM, Steven Rostedt <[email protected]> wrote:
> On Fri, 8 May 2015 07:30:39 -0700
> Drew Richardson <[email protected]> wrote:
>
>> Expose the NMI safe accessor to the monotonic raw clock to the
>> tracer. The mono clock was added with commit
>> 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. The advantage of the
>> monotonic raw clock is that it will advance more constantly than the
>> monotonic clock.
>>
>> Imagine someone is trying to optimize a particular program to reduce
>> instructions executed for a given workload while minimizing the effect
>> on runtime. Also suppose that NTP is running and potentially making
>> larger adjustments to the monotonic clock. If NTP is adjusting the
>> monotonic clock to advance more rapidly, the program will appear to
>> use fewer instructions per second but run longer than if the monotonic
>> raw clock had been used. The total number of instructions observed
>> would be the same regardless of the clock source used, but how it's
>> attributed to time would be affected.
>>
>> Conversely if NTP is adjusting the monotonic clock to advance more
>> slowly, the program will appear to use more instructions per second
>> but run more quickly. Of course there are many sources that can cause
>> jitter in performance measurements on modern processors, but let's
>> remove NTP from the list.
>>
>> The monotonic raw clock can also be useful for tracing early boot,
>> e.g. when debugging issues with NTP.
>>
>
> Peter, Thomas, John, you OK with this?
Yea. No objections from me wrt the functionality of the patch.
I'd just again maybe caution folks to not go too far in assuming
CLOCK_MONOTONIC_RAW doesn't have frequency changes, as the underlying
hardware will drift due to varying thermal conditions.
thanks
-john
On Fri, May 08, 2015 at 10:41:20AM -0400, Steven Rostedt wrote:
> On Fri, 8 May 2015 07:30:39 -0700
> Drew Richardson <[email protected]> wrote:
>
> > Expose the NMI safe accessor to the monotonic raw clock to the
> > tracer. The mono clock was added with commit
> > 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. The advantage of the
> > monotonic raw clock is that it will advance more constantly than the
> > monotonic clock.
> >
> > Imagine someone is trying to optimize a particular program to reduce
> > instructions executed for a given workload while minimizing the effect
> > on runtime. Also suppose that NTP is running and potentially making
> > larger adjustments to the monotonic clock. If NTP is adjusting the
> > monotonic clock to advance more rapidly, the program will appear to
> > use fewer instructions per second but run longer than if the monotonic
> > raw clock had been used. The total number of instructions observed
> > would be the same regardless of the clock source used, but how it's
> > attributed to time would be affected.
> >
> > Conversely if NTP is adjusting the monotonic clock to advance more
> > slowly, the program will appear to use more instructions per second
> > but run more quickly. Of course there are many sources that can cause
> > jitter in performance measurements on modern processors, but let's
> > remove NTP from the list.
> >
> > The monotonic raw clock can also be useful for tracing early boot,
> > e.g. when debugging issues with NTP.
> >
>
> Peter, Thomas, John, you OK with this?
Sure.
On Fri, 8 May 2015 09:05:24 -0700
John Stultz <[email protected]> wrote:
> Yea. No objections from me wrt the functionality of the patch.
Can I take that as an Acked-by?
>
> I'd just again maybe caution folks to not go too far in assuming
> CLOCK_MONOTONIC_RAW doesn't have frequency changes, as the underlying
> hardware will drift due to varying thermal conditions.
I totally understand this, but that's a hardware limitation (outside
the control of software). But CLOCK_MONOTONIC can drift due to software
updates, which to me, is a significant difference.
-- Steve
On Fri, May 8, 2015 at 9:15 AM, Steven Rostedt <[email protected]> wrote:
> On Fri, 8 May 2015 09:05:24 -0700
> John Stultz <[email protected]> wrote:
>
>
>> Yea. No objections from me wrt the functionality of the patch.
>
> Can I take that as an Acked-by?
Sorry, yes.
Acked-by: John Stultz <[email protected]>
On Fri, 8 May 2015, Steven Rostedt wrote:
> On Fri, 8 May 2015 07:30:39 -0700
> Drew Richardson <[email protected]> wrote:
>
> > Expose the NMI safe accessor to the monotonic raw clock to the
> > tracer. The mono clock was added with commit
> > 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. The advantage of the
> > monotonic raw clock is that it will advance more constantly than the
> > monotonic clock.
> >
> > Imagine someone is trying to optimize a particular program to reduce
> > instructions executed for a given workload while minimizing the effect
> > on runtime. Also suppose that NTP is running and potentially making
> > larger adjustments to the monotonic clock. If NTP is adjusting the
> > monotonic clock to advance more rapidly, the program will appear to
> > use fewer instructions per second but run longer than if the monotonic
> > raw clock had been used. The total number of instructions observed
> > would be the same regardless of the clock source used, but how it's
> > attributed to time would be affected.
> >
> > Conversely if NTP is adjusting the monotonic clock to advance more
> > slowly, the program will appear to use more instructions per second
> > but run more quickly. Of course there are many sources that can cause
> > jitter in performance measurements on modern processors, but let's
> > remove NTP from the list.
> >
> > The monotonic raw clock can also be useful for tracing early boot,
> > e.g. when debugging issues with NTP.
> >
>
> Peter, Thomas, John, you OK with this?
Yup.
On Tue, 12 May 2015 16:26:27 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:
> > Peter, Thomas, John, you OK with this?
>
> Yup.
I'll take that as an Ack.
OK, I'm applying it.
-- Steve