diff options
author | charliea <charliea@chromium.org> | 2015-10-22 14:49:34 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2015-10-22 21:50:27 +0000 |
commit | b164c0482b31fa65e803e03d392da9905de051cb (patch) | |
tree | 51be6199ac441d67a25b74f3c37c3f3d927c2a8e /base/time | |
parent | 7620c3c8de8b82db289524a767751f6228bc9293 (diff) | |
download | chromium_src-b164c0482b31fa65e803e03d392da9905de051cb.zip chromium_src-b164c0482b31fa65e803e03d392da9905de051cb.tar.gz chromium_src-b164c0482b31fa65e803e03d392da9905de051cb.tar.bz2 |
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
Review URL: https://codereview.chromium.org/1374753004
Cr-Commit-Position: refs/heads/master@{#355650}
Diffstat (limited to 'base/time')
-rw-r--r-- | base/time/time_posix.cc | 16 |
1 files changed, 0 insertions, 16 deletions
diff --git a/base/time/time_posix.cc b/base/time/time_posix.cc index fc82c62..2c3aaca 100644 --- a/base/time/time_posix.cc +++ b/base/time/time_posix.cc @@ -329,27 +329,11 @@ ThreadTicks ThreadTicks::Now() { #endif } -// Use the Chrome OS specific system-wide clock. -#if defined(OS_CHROMEOS) -// static -TraceTicks TraceTicks::Now() { - struct timespec ts; - if (clock_gettime(kClockSystemTrace, &ts) != 0) { - // NB: fall-back for a chrome os build running on linux - return TraceTicks(ClockNow(CLOCK_MONOTONIC)); - } - return TraceTicks(ConvertTimespecToMicros(ts)); -} - -#else // !defined(OS_CHROMEOS) - // static TraceTicks TraceTicks::Now() { return TraceTicks(ClockNow(CLOCK_MONOTONIC)); } -#endif // defined(OS_CHROMEOS) - #endif // !OS_MACOSX // static |