Makes TraceTicks use the monotonic timer on Chrome OS

Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.
He's ready to submit the second side of this CL which tells ftrace to
start using the monotonic clock as soon as this one gets DEPS rolled
into ChromeOS (sometime tomorrow morning).

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
Committed: https://crrev.com/b164c0482b31fa65e803e03d392da9905de051cb
Cr-Commit-Position: refs/heads/master@{#355650}

[charliea (OOO until 10-5), 2015-09-30 21:15:38]

charliea@chromium.org changed reviewers:
+ nduca@chromium.org

[charliea (OOO until 10-5), 2015-10-01 11:40:51]

The CQ bit was checked by charliea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-01 11:41:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1374753004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1374753004/1

[commit-bot: I haz the power, 2015-10-01 11:41:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-01 11:41:23]

Dry run: No L-G-T-M from a valid reviewer yet. Only full committers are
accepted.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[nduca, 2015-10-01 15:41:25]

have we patched the dbus endpoint of the systrace integration for chromeos to
change which clock is selected in trace start? presumably its not automatic
right? or is it?

how does the cutover from The Old Way to The New Way work? e.g. there's some
point where the kernel is old and we should use the old way, vs the kernel is
new, and vice versa?

[charliea (OOO until 10-5), 2015-10-01 16:09:14]

On 2015/10/01 15:41:25, nduca wrote:
> have we patched the dbus endpoint of the systrace integration for chromeos to
> change which clock is selected in trace start? presumably its not automatic
> right? or is it?
> 
> how does the cutover from The Old Way to The New Way work? e.g. there's some
> point where the kernel is old and we should use the old way, vs the kernel is
> new, and vice versa?

I'm going to talk with sonnyrao@ to make sure that the way that I think it will
work is actually how it will, and I'll report back.

[charliea (OOO until 10-5), 2015-10-19 20:48:17]

I talked to sonnyrao@, and he said that the evidence suggests that the usage
isn't high enough to warrant spending a lot of time on the switch over. The most
important thing is that we get everything merged well before a dev release so
that there isn't a branch during the time period in which there's the mismatch
between the two systems. Before I submit, I'll coordinate with the Chrome OS
TPMs to make sure that this doesn't happen.

[charliea (OOO until 10-5), 2015-10-19 21:15:23]

On 2015/10/19 20:48:17, charliea wrote:
> I talked to sonnyrao@, and he said that the evidence suggests that the usage
> isn't high enough to warrant spending a lot of time on the switch over. The
most
> important thing is that we get everything merged well before a dev release so
> that there isn't a branch during the time period in which there's the mismatch
> between the two systems. Before I submit, I'll coordinate with the Chrome OS
> TPMs to make sure that this doesn't happen.

I talked with the ChromeOS TPM for M48, and he said that this thursday or friday
would be a good time to submit this.

[nduca, 2015-10-19 23:05:28]

lgtm. is the follwoup bug to remove the traceticks method entirely? do we have a
bug for that clean up work self-assigned?

[charliea (OOO until 10-5), 2015-10-22 19:30:21]

Description was changed from

==========
[DO NOT SUBMIT] Makes TraceTicks use the monotonic timer on Chrome OS

(DO NOT SUBMIT until sonnyrao@ backports the Linux patch mentioned
below to the last major versions of Chrome OS, which is expected to
happen later this week.)

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=515485
==========

to

==========
[DO NOT SUBMIT] Makes TraceTicks use the monotonic timer on Chrome OS

(DO NOT SUBMIT until sonnyrao@ backports the Linux patch mentioned
below to the last major versions of Chrome OS, which is expected to
happen later this week.)

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

[charliea (OOO until 10-5), 2015-10-22 19:32:42]

On 2015/10/19 23:05:28, nduca wrote:
> lgtm. is the follwoup bug to remove the traceticks method entirely? do we have
a
> bug for that clean up work self-assigned?

Yep - I went ahead and changed the bug on this CL to the "Kill TraceTicks" bug,
because I think that this CL is more directly relevant to that than mark/measure
anyhow.

https://code.google.com/p/chromium/issues/detail?id=541692&q=owner%3Acharliea...

[charliea (OOO until 10-5), 2015-10-22 19:32:56]

The CQ bit was checked by charliea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-22 19:35:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1374753004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1374753004/1

[commit-bot: I haz the power, 2015-10-22 19:46:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-22 19:46:43]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[charliea (OOO until 10-5), 2015-10-22 21:15:41]

Description was changed from

==========
[DO NOT SUBMIT] Makes TraceTicks use the monotonic timer on Chrome OS

(DO NOT SUBMIT until sonnyrao@ backports the Linux patch mentioned
below to the last major versions of Chrome OS, which is expected to
happen later this week.)

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

to

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

[charliea (OOO until 10-5), 2015-10-22 21:16:39]

Description was changed from

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

to

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.
He's ready to submit that CL as soon as this one lands into 
ChromeOS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

[charliea (OOO until 10-5), 2015-10-22 21:39:53]

charliea@chromium.org changed reviewers:
+ thestig@chromium.org

[charliea (OOO until 10-5), 2015-10-22 21:40:52]

Description was changed from

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.
He's ready to submit that CL as soon as this one lands into 
ChromeOS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

to

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.
He's ready to submit that CL as soon as this one gets DEPS rolled
into ChromeOS (sometime tomorrow morning).

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

[charliea (OOO until 10-5), 2015-10-22 21:40:52]

Description was changed from

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.
He's ready to submit that CL as soon as this one lands into 
ChromeOS.

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

to

==========
Makes TraceTicks use the monotonic timer on Chrome OS

This is the end result of an effort to eliminate the need for TraceTicks
to be based on the ftrace clock on Chrome OS. Chrome tracing began using
the ftrace clock so that we could correlate what was happening in Chrome
(recorded in Chrome traces and thus based on TraceTicks) with what was
happening inside of the ChromeOS kernel (and thus based on the ftrace
clock). Having this end-to-end view of performance was necessary for
full-stack debugging on Chrome OS.

However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the
ability to use the monotonic clock as the source for timestamps within
ftrace. This allows us to use the monotonic clock for ftrace and thus
have the benefits of having consistent timestamps in our Chrome-level
and kernel-level tracing tools, without the cost of having to carry
around timestamps from two different sources within Chrome (the
monotonic clock for TimeTicks and the ftrace clock for TraceTicks).

sonnyrao@ graciously volunteered to backport this Linux patch to major
past versions of Chrome OS, paving the way for this patch which
finally starts using the monotonic timer for TraceTicks on Chrome OS.
He's ready to submit that CL as soon as this one gets DEPS rolled
into ChromeOS (sometime tomorrow morning).

The one down-side to all of this is that, once sonnyrao@ completes the
backports and this patch is submitted, developers with the latest
version of Chrome but with a version of ChromeOS that is not within
the most recent 5 versions will have ftrace timestamps that do not
match Chrome tracing timestamps. This shouldn't cause any functional
problems, but it will make it harder to get a full picture of
Chrome's performance down to the kernel level.

BUG=541692
==========

[Lei Zhang, 2015-10-22 21:42:18]

Seems reasonable, rs lgtm

[charliea (OOO until 10-5), 2015-10-22 21:44:58]

The CQ bit was checked by charliea@chromium.org

[commit-bot: I haz the power, 2015-10-22 21:45:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1374753004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1374753004/1

[commit-bot: I haz the power, 2015-10-22 21:49:41]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-22 21:50:39]

Patchset 1 (id:??) landed as
https://crrev.com/b164c0482b31fa65e803e03d392da9905de051cb
Cr-Commit-Position: refs/heads/master@{#355650}