summaryrefslogtreecommitdiffstats
path: root/base/time
diff options
context:
space:
mode:
authorcharliea <charliea@chromium.org>2015-10-22 14:49:34 -0700
committerCommit bot <commit-bot@chromium.org>2015-10-22 21:50:27 +0000
commitb164c0482b31fa65e803e03d392da9905de051cb (patch)
tree51be6199ac441d67a25b74f3c37c3f3d927c2a8e /base/time
parent7620c3c8de8b82db289524a767751f6228bc9293 (diff)
downloadchromium_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.cc16
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