Forward input tasks to the Blink scheduler

Forward input tasks to the Blink scheduler

Instead of posting input tasks directly to the main thread
message loop, forward them to the Blink scheduler so they
can be prioritized over other tasks.

BUG=391005
Committed: https://crrev.com/457b0a1c94129337a08d0efcc3fd016205a981b4
Cr-Commit-Position: refs/heads/master@{#293914}

[mithro-old, 2014-07-08 11:18:51]

Hi Sami,

I think I understand better now, thanks for that. Still have a question about
the following issue below?

Tim

https://codereview.chromium.org/363383002/diff/40001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/363383002/diff/40001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:719: 0, 0, 0);
This line I don't quite understand? Isn't all the state you are passing as
arguments actually captured in the begin_main_frame_state structure?

I have a CL which I'm yet to send out which changes that structure to use a
complete BeginFrameArgs rather than just a TimeTicks object.

[Sami, 2014-07-08 11:23:15]

https://codereview.chromium.org/363383002/diff/40001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/363383002/diff/40001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:719: 0, 0, 0);
On 2014/07/08 11:18:51, mithro wrote:
> This line I don't quite understand? Isn't all the state you are passing as
> arguments actually captured in the begin_main_frame_state structure?
> 
> I have a CL which I'm yet to send out which changes that structure to use a
> complete BeginFrameArgs rather than just a TimeTicks object.

Yes, the data is inside begin_main_frame_state, but since it's wrapped up in a
closure the scheduler can't see it. Because of that we need to also pass in the
relevant timestamps next to the task itself.

If BeginFrameArgs could survive a round-trip through blink then the scheduler
could just pass it back as an argument for the callback, but I'm not sure that's
necessary.

[Sami, 2014-07-18 15:35:16]

James, PTAL.

I tried writing tests for this, but turns out RenderThreadImpl has a ton of
dependencies :( However, the things I wanted to test are already pretty well
covered by the scheduler tests themselves.

[jamesr, 2014-07-22 01:07:23]

Have you measured the overhead this indirection adds?

https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
content/renderer/render_thread_impl.cc:314:
(scheduler_proxy_.*ProxyFunction)(location, new TaskAdapter(task));
hm, so another malloc/free pair for every task we post in the render process?

https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
content/renderer/render_thread_impl.cc:339: virtual void run() OVERRIDE {
function_.Run(); }
and an extra closure wrapper. hmmm

[Sami, 2014-07-22 16:24:33]

I'll report back with some perf numbers, but meanwhile I've got a question
below.

https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
content/renderer/render_thread_impl.cc:314:
(scheduler_proxy_.*ProxyFunction)(location, new TaskAdapter(task));
On 2014/07/22 01:07:23, jamesr wrote:
> hm, so another malloc/free pair for every task we post in the render process?

Yeah :( Both of these are a consequence of the fact that there's no such thing
as WebClosure that we could just hand to the scheduler. I'm guessing it's not
okay to add a dependency to base/callback.h into public/web to fix this?

[jamesr, 2014-07-22 18:11:26]

What is the lifecycle of the scheduler?  Specifically, what is the shutdown
order?

On 2014/07/22 16:24:33, Sami wrote:
> Yeah :( Both of these are a consequence of the fact that there's no such thing
> as WebClosure that we could just hand to the scheduler. I'm guessing it's not
> okay to add a dependency to base/callback.h into public/web to fix this?

You can't use base/callback from within blink, no.

[Sami, 2014-07-22 18:34:52]

On 2014/07/22 18:11:26, jamesr wrote:
> What is the lifecycle of the scheduler?  Specifically, what is the shutdown
> order?

It shuts down together with Blink, right after WTF. Are you thinking we should
have a fallback to the top-level message loop after the scheduler is gone?

[picksi1, 2014-07-29 14:53:30]

On 2014/07/22 01:07:23, jamesr wrote:
> Have you measured the overhead this indirection adds?
> 
>
https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
> File content/renderer/render_thread_impl.cc (right):
> 
>
https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
> content/renderer/render_thread_impl.cc:314:
> (scheduler_proxy_.*ProxyFunction)(location, new TaskAdapter(task));
> hm, so another malloc/free pair for every task we post in the render process?
> 
>
https://codereview.chromium.org/363383002/diff/140001/content/renderer/render...
> content/renderer/render_thread_impl.cc:339: virtual void run() OVERRIDE {
> function_.Run(); }
> and an extra closure wrapper. hmmm

I've done run the ThreadTimes metrics on the old code Vs the new code, the
results are here:

https://x20web.corp.google.com/~picksi/ThreadTimes.html

The column marked 'Baseline' is the original code, in the 'Upgrade' column is
running this patch. Each page was run 20 times. The two look essentially
identical, within the expected noise.

[Sami, 2014-08-05 18:04:34]

Now that Simon has checked that the allocations don't seem to be measurable and
I've made sure tasks can be posted even if Blink has been torn down, I think
this is ready for another look James.

[jamesr, 2014-08-07 17:59:24]

https://codereview.chromium.org/363383002/diff/200001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/200001/content/renderer/render...
content/renderer/render_thread_impl.cc:350: return
fallback_task_runner_->PostDelayedTask(from_here, task, delay);
why do you have a fallback? when is it used? are there tests that exercise it?

[Sami, 2014-08-08 11:39:17]

Thanks James, another look?

https://codereview.chromium.org/363383002/diff/200001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/200001/content/renderer/render...
content/renderer/render_thread_impl.cc:350: return
fallback_task_runner_->PostDelayedTask(from_here, task, delay);
On 2014/08/07 17:59:24, jamesr wrote:
> why do you have a fallback? when is it used? are there tests that exercise it?

I added it as a safe guard based on your comment #6, but now that I took a
closer look at the shutdown sequence I don't think it is actually needed. This
task runner is used by the input event filter and the impl thread, both of which
get torn down before we call blink::shutdown().

I've removed the fallback and added a DCHECK here.

[jamesr, 2014-08-08 17:06:49]

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
content/renderer/render_thread_impl.cc:309: // Helper for forwarding posted
tasks into different WebSchedulerProxy queues.
this belongs in its own .h/.cc and should have some basic unit tests

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
content/renderer/render_thread_impl.cc:352: virtual void run() OVERRIDE {
function_.Run(); }
NAK, you should never use OVERRIDE for cross-repository implementations. it
makes it way too hard to modify the API in question

[jamesr, 2014-08-08 17:09:01]

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
content/renderer/render_thread_impl.cc:330: from_here.file_name());
this isn't a full fidelity copy of a tracked_objects::Location.  The line number
is really useful when analyzing traces and while I haven't used the PC I know
others have.  Is there a deliberate choice here to discard information here?

[jamesr, 2014-08-08 17:52:49]

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
content/renderer/render_thread_impl.cc:331:
(scheduler_proxy_.*ProxyFunction)(location, new TaskAdapter(task));
what if you put the original tracked_objects::Location into the TaskAdapter and
then generated the trace from TaskAdapter::run()?  then you wouldn't need to
copy these values and could put fuller information in (i.e. closer to what
MessageLoop::RunTask does)

it's sad to me that we'll lose the nice tracing and tracking that base/ does for
tasks for everything that goes through the proxy. are we going to lose flow
events for these completely?

[eseidel, 2014-08-08 17:55:31]

All tasks want to have a Location.  If we're forwarding a task, we should
forward the location, if we're queueing a new one, we want to use FROM_HERE. 
Similar was discussed in https://codereview.chromium.org/439923006/ .  We added
the FROM_HERE logic to Blink a while back and it's been hugely helpful for
tracing and silk and solving random timer bugs (like crbug.com/288265).

[jamesr, 2014-08-08 18:02:33]

Having tracking information in blink is great.  Discarding parts of the tracking
information that already exists for chromium generated tasks is less great. 
This code:

https://code.google.com/p/chromium/codesearch#chromium/src/base/message_loop/...

does quite a few things that will be discarded by the task proxying in this
patch.  These are all pretty valuable - flow events make tracing analysis much
simpler, memory tagging is valuable, storing the posting PC on the stack has
been the only way we've debugged some hairy crashes in the past, etc.

In this case, the source information is coming from chromium and the task is
actually being run by chromium, blink is just deciding when to run it.  Seems
better to me to keep the tracking information stored in chromium types on the
chromium side rather than doing a lossy conversion.

[eseidel, 2014-08-08 18:09:56]

Sorry, I wasn't suggesting we should lose data.  We can either fix the
conversion to be non-lossy, or use Chromium types.  I wasn't advocating
specifically for Blink types, I was advocating for all task-like-things having
source-information.

[Sami, 2014-08-08 18:40:27]

I like the idea of tracing the task on the Chromium side without any loss of
information. I think we *also* want to pass the data (i.e., TraceLocation) to
Blink so all of the scheduler's task have location information too. I'll give
that a try.

By the way, MessageLoop::RunTask only traces the function name, file name and
the flow ID. Should we be doing something more with line numbers and PC (aside
ensuring it's on the stack)? Or is it enough to have them accessible from the
debugger?

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
content/renderer/render_thread_impl.cc:309: // Helper for forwarding posted
tasks into different WebSchedulerProxy queues.
On 2014/08/08 17:06:49, jamesr wrote:
> this belongs in its own .h/.cc and should have some basic unit tests

Done.

https://codereview.chromium.org/363383002/diff/220001/content/renderer/render...
content/renderer/render_thread_impl.cc:352: virtual void run() OVERRIDE {
function_.Run(); }
On 2014/08/08 17:06:49, jamesr wrote:
> NAK, you should never use OVERRIDE for cross-repository implementations. it
> makes it way too hard to modify the API in question

Oops, good catch!

[jamesr, 2014-08-08 19:00:16]

On 2014/08/08 18:40:27, Sami wrote:
> I like the idea of tracing the task on the Chromium side without any loss of
> information. I think we *also* want to pass the data (i.e., TraceLocation) to
> Blink so all of the scheduler's task have location information too. I'll give
> that a try.
> 

SGTM

> By the way, MessageLoop::RunTask only traces the function name, file name and
> the flow ID. Should we be doing something more with line numbers and PC (aside
> ensuring it's on the stack)? Or is it enough to have them accessible from the
> debugger?

I think we should try to do everything it does.  Ideally we'd run the same code
that MessageLoop::RunTask runs before running the task.

[Sami, 2014-08-11 12:30:07]

> > By the way, MessageLoop::RunTask only traces the function name, file name
and
> > the flow ID. Should we be doing something more with line numbers and PC
(aside
> > ensuring it's on the stack)? Or is it enough to have them accessible from
the
> > debugger?
> 
> I think we should try to do everything it does.  Ideally we'd run the same
code
> that MessageLoop::RunTask runs before running the task.

I've now factored out the debug annotation code from MessageLoop
(https://codereview.chromium.org/455833004/) and rewritten this patch to use it.

[Sami, 2014-08-11 13:43:22]

FYI, I also had to remove the DCHECK for RenderThreadImpl::current() since turns
out it's backed by TLS and thus not queryable from other threads.

[Sami, 2014-08-14 16:26:06]

How's this looking now? (The try job crashes were due to
https://codereview.chromium.org/475033002/).

[jamesr, 2014-08-14 17:26:00]

number of style issues to address before landing but otherwise lgtm. the task
annotator is nifty

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
File content/renderer/scheduler_proxy_task_runner.h (right):

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner.h:18: const
blink::WebTraceLocation&,
this is chromium, parameters get names

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner.h:61: explicit
TaskAdapter(base::debug::TaskAnnotator& task_annotator,
this should be a pointer, not a non-const ref. same goes for the member. blink's
moved over to using refs for things that should never be null but chromium has
not

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
File content/renderer/scheduler_proxy_task_runner_browsertest.cc (right):

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner_browsertest.cc:17: void
testTask(int value, int* result) {
this is chromium, functions get UpperCase names

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner_browsertest.cc:23: class
SchedulerProxyTaskRunnerBrowserTest : public testing::Test {
this fixture doesn't do anything - why even have it?  you can delete this and
have TEST(SchedulerProxyTaskRunnerBrowserTest, FooBar)

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner_browsertest.cc:42:
base::MessageLoopForIO message_loop_;
this is not a member variable, no trailing _

[Sami, 2014-08-15 10:16:16]

Thanks, all comments addressed.

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
File content/renderer/scheduler_proxy_task_runner.h (right):

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner.h:18: const
blink::WebTraceLocation&,
On 2014/08/14 17:25:59, jamesr wrote:
> this is chromium, parameters get names

Done.

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner.h:61: explicit
TaskAdapter(base::debug::TaskAnnotator& task_annotator,
On 2014/08/14 17:25:59, jamesr wrote:
> this should be a pointer, not a non-const ref. same goes for the member.
blink's
> moved over to using refs for things that should never be null but chromium has
> not

Thanks, I hadn't picked up on that. Done.

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
File content/renderer/scheduler_proxy_task_runner_browsertest.cc (right):

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner_browsertest.cc:17: void
testTask(int value, int* result) {
On 2014/08/14 17:26:00, jamesr wrote:
> this is chromium, functions get UpperCase names

Done.

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner_browsertest.cc:23: class
SchedulerProxyTaskRunnerBrowserTest : public testing::Test {
On 2014/08/14 17:26:00, jamesr wrote:
> this fixture doesn't do anything - why even have it?  you can delete this and
> have TEST(SchedulerProxyTaskRunnerBrowserTest, FooBar)

Yup, no need for this. Done.

https://codereview.chromium.org/363383002/diff/320001/content/renderer/schedu...
content/renderer/scheduler_proxy_task_runner_browsertest.cc:42:
base::MessageLoopForIO message_loop_;
On 2014/08/14 17:26:00, jamesr wrote:
> this is not a member variable, no trailing _

Done.

[Sami, 2014-08-15 10:16:23]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-15 10:17:35]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/340001

[commit-bot: I haz the power, 2014-08-15 13:51:26]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tri...)
  linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[commit-bot: I haz the power, 2014-08-15 14:29:04]

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

[commit-bot: I haz the power, 2014-08-15 14:29:05]

Try jobs failed on following builders:
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Sami, 2014-08-15 15:38:33]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-15 15:42:34]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/340001

[commit-bot: I haz the power, 2014-08-15 17:11:34]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tri...)
  linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[commit-bot: I haz the power, 2014-08-15 17:51:44]

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

[commit-bot: I haz the power, 2014-08-15 17:51:45]

Try jobs failed on following builders:
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Sami, 2014-08-15 22:19:01]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-15 22:20:35]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/340001

[commit-bot: I haz the power, 2014-08-16 00:23:55]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[commit-bot: I haz the power, 2014-08-16 01:25:27]

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

[commit-bot: I haz the power, 2014-08-16 01:25:28]

Try jobs failed on following builders:
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Sami, 2014-08-18 09:41:44]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-18 09:42:39]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/340001

[commit-bot: I haz the power, 2014-08-18 13:16:58]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[commit-bot: I haz the power, 2014-08-18 14:17:10]

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

[commit-bot: I haz the power, 2014-08-18 14:17:11]

Try jobs failed on following builders:
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Sami, 2014-08-19 22:59:48]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-19 23:00:55]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/360001

[commit-bot: I haz the power, 2014-08-19 23:11:08]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...)
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/43882)
  win_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu/builds/49051)
  android_aosp on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_aosp/bu...)
  android_chromium_gn_compile_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)
  android_clang_dbg on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_gn_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device/bu...)
  ios_rel_device_ninja on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win8_chromium_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...)
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[commit-bot: I haz the power, 2014-08-19 23:13:18]

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

[commit-bot: I haz the power, 2014-08-19 23:13:19]

Try jobs failed on following builders:
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/43884)
  ios_dbg_simulator on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device/bu...)
  ios_rel_device_ninja on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Sami, 2014-08-20 10:44:29]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-20 10:45:29]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/380001

[commit-bot: I haz the power, 2014-08-20 12:03:44]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[commit-bot: I haz the power, 2014-08-20 16:33:10]

Committed patchset #20 (380001) as 290845

[Sami, 2014-09-05 08:18:50]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-09-05 08:21:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/400001

[commit-bot: I haz the power, 2014-09-05 11:58:09]

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

[commit-bot: I haz the power, 2014-09-05 11:58:11]

Try jobs failed on following builders:
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Sami, 2014-09-05 12:06:46]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-09-05 12:08:19]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/400001

[commit-bot: I haz the power, 2014-09-05 13:32:37]

Committed patchset #21 (id:400001) as 68bab3290b45a8610ad875d3c92530477c16a948

[jam, 2014-09-08 07:00:04]

A revert of this CL (patchset #21 id:400001) has been created in
https://codereview.chromium.org/548253002/ by jam@chromium.org.

The reason for reverting is: suspecting it's causing the high rate of flakes in
Instrumentation test ContentShellTest

BUG=411756.

[Sami, 2014-09-08 15:02:49]

A revert of this CL (patchset #21 id:400001) has been created in
https://codereview.chromium.org/553483005/ by skyostil@chromium.org.

The reason for reverting is: 13% regression on page load times.

BUG=411520.

[eseidel, 2014-09-08 16:10:03]

Flakes would be concerning.  But PLT regressions are not necessarily surprising
or bad.  When we land this again we should be sure to call out what regressions
are expected in the commit-message/CL-description so that perf-sheriffs won't be
surprised.

[Sami, 2014-09-08 16:50:48]

To reduce the moving parts a little I've made this patch just forward input
tasks to the scheduler for now. We'll turn on scheduling for compositor tasks
once the remaining issues there are solved.

[Sami, 2014-09-08 16:52:03]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-09-08 16:53:47]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/420001

[commit-bot: I haz the power, 2014-09-08 18:55:07]

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

[commit-bot: I haz the power, 2014-09-08 18:55:09]

Exceeded time limit waiting for builds to trigger.

[Sami, 2014-09-09 09:34:35]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-09-09 09:35:40]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/363383002/420001

[commit-bot: I haz the power, 2014-09-09 10:12:56]

Committed patchset #22 (id:420001) as 46e1901b668dbd357ca236b43cf2907c0dd9bb19

[commit-bot: I haz the power, 2014-09-10 03:39:18]

Patchset 22 (id:??) landed as
https://crrev.com/796a67f0004f091f6e71a02b982d6727213da685
Cr-Commit-Position: refs/heads/master@{#293513}

[commit-bot: I haz the power, 2014-09-10 03:52:37]

Patchset 22 (id:??) landed as
https://crrev.com/457b0a1c94129337a08d0efcc3fd016205a981b4
Cr-Commit-Position: refs/heads/master@{#293914}