cc: Measure compositor timing with finer granularity

cc: Measure compositor timing with finer granularity

Measures PrepareTiles, NotifyReadyToActivate, and
Activation times separately such that idle times
between actions don't polute results when the
main thread is in a high latency mode or when
actions are swap throttled.

Also cleans up how we measure commit times and
adds DCHECKs to make sure we don't ruin the ordering
expectations of the CompositorTimingHistory class.

Recording is only enabled while visible and we have
an output surface in order to avoid cleanup logic
skewing results.

BUG=406158, 500744
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/65acb94f9258f985cbceedcd3b816cc55cc9522f
Cr-Commit-Position: refs/heads/master@{#337539}

Committed: https://crrev.com/6874981ce0fc8bb4f8a61954136caec3c4c622ad
Cr-Commit-Position: refs/heads/master@{#337700}

[brianderson, 2015-06-19 02:48:03]

brianderson@chromium.org changed reviewers:
+ mithro@mithis.com, sunnyps@chromium.org

[brianderson, 2015-06-19 02:48:04]

ptal!

[picksi, 2015-06-19 13:04:27]

picksi@google.com changed reviewers:
+ picksi@google.com

[picksi, 2015-06-19 13:04:28]

A couple of comments from a someone who doesn't know the code at all :)

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/compositor...
File cc/scheduler/compositor_timing_history.cc (right):

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history.cc:107: base::TimeTicks::Now() -
start_prepare_tiles_time_;
Is there some C++ magic going on here that I'm missing? The result of
base::TimeTicks::Now() - start_prepare_tiles_time_; seems to unused.

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/scheduler_...
File cc/scheduler/scheduler_unittest.cc (right):

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/scheduler_...
cc/scheduler/scheduler_unittest.cc:150: scheduler_->DidPrepareTiles();
You seem to be measuring nothing here?

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/scheduler_...
cc/scheduler/scheduler_unittest.cc:1307: SetUpScheduler(true);
I see it is a common pattern, but SetUpScheduler(true) leaves me not knowing
what the 'true' means. Is it worth either making a wrapper function
SetUpSchedulerWithLogging() [you see, I really have no idea what the 'true'
means], or having a const/enum to pass as a self explanatory parameter?

[brianderson, 2015-06-19 17:24:27]

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/compositor...
File cc/scheduler/compositor_timing_history.cc (right):

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history.cc:107: base::TimeTicks::Now() -
start_prepare_tiles_time_;
On 2015/06/19 13:04:28, picksi wrote:
> Is there some C++ magic going on here that I'm missing? The result of
> base::TimeTicks::Now() - start_prepare_tiles_time_; seems to unused.

That would be pretty magical. I should add some simple unit tests.

THanks for catching that.

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/scheduler_...
File cc/scheduler/scheduler_unittest.cc (right):

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/scheduler_...
cc/scheduler/scheduler_unittest.cc:150: scheduler_->DidPrepareTiles();
On 2015/06/19 13:04:28, picksi wrote:
> You seem to be measuring nothing here?

Every WillPrepareTiles must be followed by a DidPrepareTiles to avoid the DCHECK
in CompositorTimingHistory.

The scheduler tests themselves fake the estimations, so the actual timing
doesn't matter.

https://codereview.chromium.org/1192663005/diff/20001/cc/scheduler/scheduler_...
cc/scheduler/scheduler_unittest.cc:1307: SetUpScheduler(true);
On 2015/06/19 13:04:28, picksi wrote:
> I see it is a common pattern, but SetUpScheduler(true) leaves me not knowing
> what the 'true' means. Is it worth either making a wrapper function
> SetUpSchedulerWithLogging() [you see, I really have no idea what the 'true'
> means], or having a const/enum to pass as a self explanatory parameter?

Good idea. I can clean that up in a separate patch.

[brianderson, 2015-06-19 23:41:54]

Updated a few things:
* Added unit tests.
* OutputSurfaceState and visibility are taken into account regarding whether we
record samples.
* Recordings are discarded until 2 draws after being enabled since they are
likely to be outliers.

[mithro-old, 2015-06-23 09:02:39]

On 2015/06/19 23:41:54, brianderson wrote:
> Updated a few things:
> * Added unit tests.
> * OutputSurfaceState and visibility are taken into account regarding whether
we
> record samples.
> * Recordings are discarded until 2 draws after being enabled since they are
> likely to be outliers.

How does this CL related to https://codereview.chromium.org/1184863004/ now?

Tim

[brianderson, 2015-06-23 15:59:41]

On 2015/06/23 09:02:39, mithro wrote:
> On 2015/06/19 23:41:54, brianderson wrote:
> > Updated a few things:
> > * Added unit tests.
> > * OutputSurfaceState and visibility are taken into account regarding whether
> we
> > record samples.
> > * Recordings are discarded until 2 draws after being enabled since they are
> > likely to be outliers.
> 
> How does this CL related to https://codereview.chromium.org/1184863004/ now?
> 
> Tim

The previous CL was a refactoring change. This one is more of a behavior change.
I updated the patch description explaining that measuring with finer granularity
gives us better measurements for when we are swap throttled or when we are in
high latency mode.

[brianderson, 2015-06-24 02:34:39]

Rebased on top of https://codereview.chromium.org/1184863004/.

I can split this patch up too if people want.

[brianderson, 2015-06-24 05:23:51]

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

[commit-bot: I haz the power, 2015-06-24 05:24:02]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1192663005/60001

[commit-bot: I haz the power, 2015-06-24 06:40:59]

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

[commit-bot: I haz the power, 2015-06-24 06:41:00]

Dry run: This issue passed the CQ dry run.

[brianderson, 2015-06-24 23:22:03]

Decided to split out the "don't record first 2 frames logic".

[sunnyps, 2015-06-24 23:34:13]

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
File cc/scheduler/compositor_timing_history.h (right):

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history.h:30: virtual base::TimeDelta
PrepareTilesBeginToReadyToActivateDurationEstimate()
Why is this not called CommitToReadyToActivateDurationEstimate like in other
places?

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
File cc/scheduler/compositor_timing_history_unittest.cc (right):

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history_unittest.cc:24:
CompositorTimingHistoryTest* test_;
nit: DISALLOW_COPY_AND_ASSIGN

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history_unittest.cc:38: base::TimeTicks Now() {
return now_; }
nit: const?

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history_unittest.cc:43: base::TimeTicks now_;
nit: DISALLOW_COPY_AND_ASSIGN

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history_unittest.cc:67: // Do not count idle time
between commit and prepare tiles.
Is the time between commit and prepare tiles really that significant?

[brianderson, 2015-06-24 23:46:16]

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
File cc/scheduler/compositor_timing_history.h (right):

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history.h:30: virtual base::TimeDelta
PrepareTilesBeginToReadyToActivateDurationEstimate()
On 2015/06/24 23:34:12, sunnyps wrote:
> Why is this not called CommitToReadyToActivateDurationEstimate like in other
> places?

See other comment.

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
File cc/scheduler/compositor_timing_history_unittest.cc (right):

https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
cc/scheduler/compositor_timing_history_unittest.cc:67: // Do not count idle time
between commit and prepare tiles.
On 2015/06/24 23:34:13, sunnyps wrote:
> Is the time between commit and prepare tiles really that significant?

Not today, but the checkerboard avoidance patch
(https://codereview.chromium.org/1131633003/) does not always prepare tiles
immediately after commit.

It's also the reason why CommitToReadyToActivateDurationEstimate doesn't quite
map. I should get rid all references to CommitToReadyToActivateDurationEstimate
as part of this patch.

Alternatively, I can pull out this part of the patch until we really need it for
checkerboarding, if preferred.

[sunnyps, 2015-06-24 23:48:59]

On 2015/06/24 23:46:16, brianderson wrote:
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> File cc/scheduler/compositor_timing_history.h (right):
> 
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> cc/scheduler/compositor_timing_history.h:30: virtual base::TimeDelta
> PrepareTilesBeginToReadyToActivateDurationEstimate()
> On 2015/06/24 23:34:12, sunnyps wrote:
> > Why is this not called CommitToReadyToActivateDurationEstimate like in other
> > places?
> 
> See other comment.
> 
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> File cc/scheduler/compositor_timing_history_unittest.cc (right):
> 
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> cc/scheduler/compositor_timing_history_unittest.cc:67: // Do not count idle
time
> between commit and prepare tiles.
> On 2015/06/24 23:34:13, sunnyps wrote:
> > Is the time between commit and prepare tiles really that significant?
> 
> Not today, but the checkerboard avoidance patch
> (https://codereview.chromium.org/1131633003/) does not always prepare tiles
> immediately after commit.
> 
> It's also the reason why CommitToReadyToActivateDurationEstimate doesn't quite
> map. I should get rid all references to
CommitToReadyToActivateDurationEstimate
> as part of this patch.
> 
> Alternatively, I can pull out this part of the patch until we really need it
for
> checkerboarding, if preferred.

Let's put it in later when needed.

[brianderson, 2015-06-30 02:13:14]

On 2015/06/24 23:48:59, sunnyps wrote:
> On 2015/06/24 23:46:16, brianderson wrote:
> >
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> > File cc/scheduler/compositor_timing_history.h (right):
> > 
> >
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> > cc/scheduler/compositor_timing_history.h:30: virtual base::TimeDelta
> > PrepareTilesBeginToReadyToActivateDurationEstimate()
> > On 2015/06/24 23:34:12, sunnyps wrote:
> > > Why is this not called CommitToReadyToActivateDurationEstimate like in
other
> > > places?
> > 
> > See other comment.
> > 
> >
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> > File cc/scheduler/compositor_timing_history_unittest.cc (right):
> > 
> >
>
https://codereview.chromium.org/1192663005/diff/80001/cc/scheduler/compositor...
> > cc/scheduler/compositor_timing_history_unittest.cc:67: // Do not count idle
> time
> > between commit and prepare tiles.
> > On 2015/06/24 23:34:13, sunnyps wrote:
> > > Is the time between commit and prepare tiles really that significant?
> > 
> > Not today, but the checkerboard avoidance patch
> > (https://codereview.chromium.org/1131633003/) does not always prepare tiles
> > immediately after commit.
> > 
> > It's also the reason why CommitToReadyToActivateDurationEstimate doesn't
quite
> > map. I should get rid all references to
> CommitToReadyToActivateDurationEstimate
> > as part of this patch.
> > 
> > Alternatively, I can pull out this part of the patch until we really need it
> for
> > checkerboarding, if preferred.
> 
> Let's put it in later when needed.

Gone.

I think all comments are addressed now. ptal!

[mithro-old, 2015-06-30 07:55:50]

Some minor comments but generally LGTM.

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
File cc/scheduler/compositor_timing_history.cc (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:12: const double
kBeginMainFrameToCommitEstimationPercentile = 50.0;
Why are these percentiles set to these values? Can you add a comment about how
they ended up like this?

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:35: base::trace_event::TracedValue*
state) const {
Can you put these in the same order as they are defined? Makes it easier to
check you haven't missed one.

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:94: void
CompositorTimingHistory::BeginMainFrameAborted() {
Does it make sense to include aborted commits in the timing history?

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:198: void
CompositorTimingHistory::AddDrawDurationUMA(
Are you planning on adding UMAs for the other ones in the future too?

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
File cc/scheduler/compositor_timing_history.h (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.h:55: RollingTimeDeltaHistory
begin_main_frame_to_commit_duration_history_;
Can we record the delta between when the commit was ready and when we actually
did the commit?

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.h:57: RollingTimeDeltaHistory
prepare_tiles_duration_history_;
It would be interesting in the future to have a way to ask "given this task has
taken 5ms so far, how much longer do you think it would take".

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.h:59: RollingTimeDeltaHistory
draw_duration_history_;
I think it would also be useful to record the following;

 * The delta between when a task *could* run and when we actually got around to
running it. IE The above delta between "when the main thread said the commit was
ready" verses "when we actually started the commit".

 * The delta between successive run. IE between the start of two
BeginMainFrame).

Maybe something to add in another CL though?

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_unittest.cc (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/scheduler...
cc/scheduler/scheduler_unittest.cc:130: void ScheduledActionCommit() override {
Why didn't any tests previously depend on this happening!?

https://codereview.chromium.org/1192663005/diff/120001/cc/test/scheduler_test...
File cc/test/scheduler_test_common.cc (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/test/scheduler_test...
cc/test/scheduler_test_common.cc:86: void
FakeCompositorTimingHistory::SetBeginMainFrameToCommitDurationEstimate(
Any resound these moved around?

[brianderson, 2015-06-30 17:35:15]

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
File cc/scheduler/compositor_timing_history.cc (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:12: const double
kBeginMainFrameToCommitEstimationPercentile = 50.0;
On 2015/06/30 07:55:49, mithro wrote:
> Why are these percentiles set to these values? Can you add a comment about how
> they ended up like this?

These were picked somewhat arbitrarily a while back and we never tuned them. We
should revisit the choices.

The ones that are 100 percentile are used to calculate the compositor deadline,
where it's really important we don't miss it.

The 50 percentile ones are used to calculate main thread response time. This
affects when we attempt to skip the BeginMainFrame and the overall smoothness of
the main thread. We should probably revisit the 50 percentile decision there.

Will add comments.

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:35: base::trace_event::TracedValue*
state) const {
On 2015/06/30 07:55:49, mithro wrote:
> Can you put these in the same order as they are defined? Makes it easier to
> check you haven't missed one.

Acknowledged.

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.cc:198: void
CompositorTimingHistory::AddDrawDurationUMA(
On 2015/06/30 07:55:49, mithro wrote:
> Are you planning on adding UMAs for the other ones in the future too?

Yes. We are going to do it for PrepareTiles - will probably make sense to do it
for all of them.

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
File cc/scheduler/compositor_timing_history.h (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/composito...
cc/scheduler/compositor_timing_history.h:59: RollingTimeDeltaHistory
draw_duration_history_;
On 2015/06/30 07:55:49, mithro wrote:
> I think it would also be useful to record the following;
> 
>  * The delta between when a task *could* run and when we actually got around
to
> running it. IE The above delta between "when the main thread said the commit
was
> ready" verses "when we actually started the commit".
> 
>  * The delta between successive run. IE between the start of two
> BeginMainFrame).
> 
> Maybe something to add in another CL though?

Acknowledged.

Some of those would probably fit better in LatencyInfo though. The measurements
in this class are used to make scheduling decisions and I don't think we have an
immediate use for those measurements in scheduling decisions.

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/scheduler...
File cc/scheduler/scheduler_unittest.cc (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/scheduler/scheduler...
cc/scheduler/scheduler_unittest.cc:130: void ScheduledActionCommit() override {
On 2015/06/30 07:55:49, mithro wrote:
> Why didn't any tests previously depend on this happening!?

I added Scheduler::DidCommit as part of this patch, so it's more clear when the
commit actually finished. (The LTHI can do extra work after the commit that the
Scheduler isn't aware of.)

https://codereview.chromium.org/1192663005/diff/120001/cc/test/scheduler_test...
File cc/test/scheduler_test_common.cc (right):

https://codereview.chromium.org/1192663005/diff/120001/cc/test/scheduler_test...
cc/test/scheduler_test_common.cc:86: void
FakeCompositorTimingHistory::SetBeginMainFrameToCommitDurationEstimate(
On 2015/06/30 07:55:49, mithro wrote:
> Any resound these moved around?

I wanted to put them in the approximate order we'd see a commit hit them. I'll
make them consistent.

[brianderson, 2015-06-30 18:07:45]

Addressed Tim's comments. Sunny - did you want to have another look?

[sunnyps, 2015-07-07 00:00:22]

On 2015/06/30 18:07:45, brianderson wrote:
> Addressed Tim's comments. Sunny - did you want to have another look?

LGTM

[brianderson, 2015-07-07 00:02:17]

The CQ bit was checked by brianderson@chromium.org

[brianderson, 2015-07-07 00:02:17]

The patchset sent to the CQ was uploaded after l-g-t-m from mithro@mithis.com
Link to the patchset: https://codereview.chromium.org/1192663005/#ps140001
(title: "make order consistent; add comment")

[commit-bot: I haz the power, 2015-07-07 00:02:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1192663005/140001

[commit-bot: I haz the power, 2015-07-07 01:08:33]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2015-07-07 01:09:23]

Patchset 8 (id:??) landed as
https://crrev.com/65acb94f9258f985cbceedcd3b816cc55cc9522f
Cr-Commit-Position: refs/heads/master@{#337539}

[tapted, 2015-07-07 03:00:28]

A revert of this CL (patchset #8 id:140001) has been created in
https://codereview.chromium.org/1213653005/ by tapted@chromium.org.

The reason for reverting is: Flakily fails interactive_ui_tests on Linux Tests
(dbg)(1)(32). Link:

https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%2...

failures:
AppWindowHiddenKeepAliveTest.ShownThenHiddenThenShown

Error:
[1:8:0706/185834:FATAL:compositor_timing_history.cc(104)] Check failed:
base::TimeTicks() != begin_main_frame_sent_time_ (0 bogo-microseconds vs. 0
bogo-microseconds)
#0 0x0000ebbb49f4 base::debug::StackTrace::StackTrace()
#1 0x0000ebc17bee logging::LogMessage::~LogMessage()
#2 0x0000eec044b4 cc::CompositorTimingHistory::DidCommit()
#3 0x0000eec043ab cc::CompositorTimingHistory::BeginMainFrameAborted()
#4 0x0000eec0cfa5 cc::Scheduler::BeginMainFrameAborted()
#5 0x0000eed51290 cc::ThreadProxy::BeginMainFrameAbortedOnImplThread()
#6 0x0000eed60235 base::internal::RunnableAdapter\u003C>::Run()

See also:

https://findit-for-me.appspot.com/build-failure?url=https://build.chromium.or....

[brianderson, 2015-07-07 17:45:50]

On 2015/07/07 03:00:28, tapted wrote:
> A revert of this CL (patchset #8 id:140001) has been created in
> https://codereview.chromium.org/1213653005/ by mailto:tapted@chromium.org.
> 
> The reason for reverting is: Flakily fails interactive_ui_tests on Linux Tests
> (dbg)(1)(32). Link:
> 
>
https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%2...
> 
> failures:
> AppWindowHiddenKeepAliveTest.ShownThenHiddenThenShown
> 
> Error:
> [1:8:0706/185834:FATAL:compositor_timing_history.cc(104)] Check failed:
> base::TimeTicks() != begin_main_frame_sent_time_ (0 bogo-microseconds vs. 0
> bogo-microseconds)
> #0 0x0000ebbb49f4 base::debug::StackTrace::StackTrace()
> #1 0x0000ebc17bee logging::LogMessage::~LogMessage()
> #2 0x0000eec044b4 cc::CompositorTimingHistory::DidCommit()
> #3 0x0000eec043ab cc::CompositorTimingHistory::BeginMainFrameAborted()
> #4 0x0000eec0cfa5 cc::Scheduler::BeginMainFrameAborted()
> #5 0x0000eed51290 cc::ThreadProxy::BeginMainFrameAbortedOnImplThread()
> #6 0x0000eed60235 base::internal::RunnableAdapter\u003C>::Run()
> 
> See also:
> 
>
https://findit-for-me.appspot.com/build-failure?url=https://build.chromium.or....

Thanks for reverting, tapted. The DCHECK doesn't apply when recording is
disabled. I've updated the DCHECKs.

[brianderson, 2015-07-07 17:46:12]

The CQ bit was checked by brianderson@chromium.org

[brianderson, 2015-07-07 17:46:12]

The patchset sent to the CQ was uploaded after l-g-t-m from
sunnyps@chromium.org, mithro@mithis.com
Link to the patchset: https://codereview.chromium.org/1192663005/#ps160001
(title: "fix dcheck assumptions")

[commit-bot: I haz the power, 2015-07-07 17:47:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1192663005/160001

[brianderson, 2015-07-07 18:04:26]

The CQ bit was unchecked by brianderson@chromium.org

[brianderson, 2015-07-07 21:15:30]

The CQ bit was checked by brianderson@chromium.org

[brianderson, 2015-07-07 21:15:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
sunnyps@chromium.org, mithro@mithis.com
Link to the patchset: https://codereview.chromium.org/1192663005/#ps180001
(title: "don't reset timing history")

[commit-bot: I haz the power, 2015-07-07 21:17:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1192663005/180001

[commit-bot: I haz the power, 2015-07-07 22:39:48]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2015-07-07 22:40:47]

Patchset 10 (id:??) landed as
https://crrev.com/6874981ce0fc8bb4f8a61954136caec3c4c622ad
Cr-Commit-Position: refs/heads/master@{#337700}