Add setting to disable latency recovery for tests

Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544
Committed: https://crrev.com/eb16f56d14abc73321c5128b0374f94c747aa9db
Cr-Commit-Position: refs/heads/master@{#419573}

[enne (OOO), 2016-09-19 18:27:38]

Description was changed from

==========
Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544
==========

to

==========
Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[enne (OOO), 2016-09-19 18:27:59]

Description was changed from

==========
Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544
==========

[enne (OOO), 2016-09-19 18:28:05]

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

[commit-bot: I haz the power, 2016-09-19 18:28:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-19 20:15:42]

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

[commit-bot: I haz the power, 2016-09-19 20:15:43]

Dry run: This issue passed the CQ dry run.

[brianderson, 2016-09-19 20:50:46]

lgtm

[enne (OOO), 2016-09-19 21:13:28]

The CQ bit was checked by enne@chromium.org

[commit-bot: I haz the power, 2016-09-19 21:14:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-19 21:47:10]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-19 21:50:22]

Description was changed from

==========
Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544
==========

to

==========
Add setting to disable latency recovery for tests

The scheduler uses timing history (and other inputs) to decide if it
should try to recover latency.  This makes some tests dependent
on timing in terms of whether the scheduler will ever send a begin
frame (or not, if it's trying to recover main thread latency).  In
some cases, this also can cause a live lock in tests where the
scheduler is waiting for activation to send a begin frame and the
activation is waiting for a begin frame before it lets itself finish.
This has been fixed in the past by just making the tests tick quicker,
but that's not very future proof.

So, in order to make cc tests more robust, add a setting that disables
all latency recover in the scheduler.

R=brianderson@chromium.org
BUG=632544

Committed: https://crrev.com/eb16f56d14abc73321c5128b0374f94c747aa9db
Cr-Commit-Position: refs/heads/master@{#419573}
==========

[commit-bot: I haz the power, 2016-09-19 21:50:23]

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