NOCOMMIT prototype: GRC service plumbing and process priority

Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be split up and have tests added, after feedback.

GRC parent doc (internal only): https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTbC4/edit#heading=h.td4yhfm12fe3

This CL depends on https://codereview.chromium.org/2798713002

This thing should theoretically improve https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are worked out, by lowering process priority for background tabs even before they've started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the browser process through a CoordinationUnitInterface, and can be duplicated on demand from other processes (there's an example in the CL of Blink hooking up to the frame-level CoordinationUnit). It can be used to send events through (currently just basic enums with no args), and can be used to set a callback if the client of the CoordinationUnit is interested in receiving resource policy updates (as shown by RenderProcessHostImpl, which receives a should_background policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps around the CoordinationUnit for easier usage, and has functionality to set up parent/child relationships between different units.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

[oystein (OOO til 10th of July), 2017-02-22 02:35:39]

Description was changed from

==========
WIP NOCOMMIT: GRC pipes

BUG=
==========

to

==========
WIP NOCOMMIT: GRC pipes

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[oystein (OOO til 10th of July), 2017-03-15 20:34:51]

Description was changed from

==========
WIP NOCOMMIT: GRC pipes

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
NOCOMMIT prototype: GRC service plumbing and process priority

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

[oystein (OOO til 10th of July), 2017-03-15 20:46:36]

Description was changed from

==========
NOCOMMIT prototype: GRC service plumbing and process priority

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

to

==========
NOCOMMIT prototype: GRC service plumbing and process priority

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

[oystein (OOO til 10th of July), 2017-03-15 20:47:01]

oysteine@chromium.org changed reviewers:
+ rockot@chromium.org

[oystein (OOO til 10th of July), 2017-03-15 20:47:41]

rockot: Has prototype. Unsure if remotely sane. Plx advice.

[oystein (OOO til 10th of July), 2017-03-15 21:04:31]

Description was changed from

==========
NOCOMMIT prototype: GRC service plumbing and process priority

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

to

==========
Global Resource Controller

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

[oystein (OOO til 10th of July), 2017-03-15 21:10:19]

Description was changed from

==========
Global Resource Controller

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

to

==========
Global Resource Controller

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

[oystein (OOO til 10th of July), 2017-03-15 21:12:38]

Description was changed from

==========
Global Resource Controller

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

to

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

[Ken Rockot(use gerrit already), 2017-03-15 22:51:55]

Looks pretty good overall

https://codereview.chromium.org/2710823003/diff/380001/services/resource_coor...
File services/resource_coordinator/public/interfaces/coordination_unit.mojom
(right):

https://codereview.chromium.org/2710823003/diff/380001/services/resource_coor...
services/resource_coordinator/public/interfaces/coordination_unit.mojom:35:
AddChild(CoordinationUnitID child_id);
I haven't fully understood the design here, so I might be spouting stupid
nonsense. Is it possible to avoid having this notion of a "CoordinationUnitID"
by making the hierarchy a permanent implicit property of CoordinationUnits? i.e.
could we somehow build this system with the interface looking more like:

interface CoordinationUnit {
  SendEvent(Event event);
  Duplicate(CoordinationUnit& request);
  AddChild(CoordinationUnit& request);
  SetPolicyCallback(PolicyCallback callback);
};

?

https://codereview.chromium.org/2710823003/diff/380001/services/resource_coor...
File services/resource_coordinator/resource_coordinator_service.cc (right):

https://codereview.chromium.org/2710823003/diff/380001/services/resource_coor...
services/resource_coordinator/resource_coordinator_service.cc:43:
std::unique_ptr<service_manager::ServiceContextRef> connection_ref =
So as a preface, the ServiceContextRef stuff is kind of unfortunate, but we
don't yet have a better way of essentially ref-counting the service itself to
keep track of whether or not it's still in use. The idea is once the ref count
(i.e. the number of ServiceContextRef instances) goes to zero, we automatically
call RequestQuit and signal to the Service Manager that it can shut us down.

That means that in order to use it properly, you essentially need to hold a
corresponding ServiceContextRef for every active binding in your service.
Otherwise you may get killed while someone is still connected to one of your
interfaces.

So you'll want to provide CoordinationUnitProvider::Create with a reference to
ref_factory_, and have the impl call CreateRef and retain the returned
ServiceContextRef. You'll want to do the same thing for every CoordinationUnit
as well, passing a new ServiceContextRef into its constructor along with the
incoming CoordinationUnit request.

This is an unhappy situation and I'd like to find a way to hide all these
details and essentially automate the bookkeeping (e.g. by automatically tagging
incoming InterfaceRequests with some context, and having that propagate to
bindings), but for now it's the thing to do.

[oystein (OOO til 10th of July), 2017-03-15 23:12:24]

Thanks!!

https://codereview.chromium.org/2710823003/diff/380001/services/resource_coor...
File services/resource_coordinator/public/interfaces/coordination_unit.mojom
(right):

https://codereview.chromium.org/2710823003/diff/380001/services/resource_coor...
services/resource_coordinator/public/interfaces/coordination_unit.mojom:35:
AddChild(CoordinationUnitID child_id);
On 2017/03/15 at 22:51:55, Ken Rockot wrote:
> I haven't fully understood the design here, so I might be spouting stupid
nonsense. Is it possible to avoid having this notion of a "CoordinationUnitID"
by making the hierarchy a permanent implicit property of CoordinationUnits? i.e.
could we somehow build this system with the interface looking more like:
> 
> interface CoordinationUnit {
>   SendEvent(Event event);
>   Duplicate(CoordinationUnit& request);
>   AddChild(CoordinationUnit& request);
>   SetPolicyCallback(PolicyCallback callback);
> };
> 
> ?

I'd love to get rid of CoordinationUnitID, but unfortunately since a
CoordinationUnit can have multiple parents (it's a DAG rather than a tree), I
need to be able to form a connection without creating a new node at the same
time :/. I was trying to see if there's some kind of Mojo binding ID or
something I could use instead but didn't have much luck.

[oystein (OOO til 10th of July), 2017-03-16 02:26:59]

Description was changed from

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
==========

to

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[r52537455, 2017-03-22 12:39:11]

Actually i dont have any idea about the  GRC service plumbing and process
priority.Now i got some information.This information is really help me to add
some information in my website - http://adeptsol.com/.thank you so much .

[Sami, 2017-03-22 13:51:41]

skyostil@chromium.org changed reviewers:
+ skyostil@chromium.org

[Sami, 2017-03-22 13:51:43]

I think this looks great! Left a few miscellaneous comments -- I'll reply to the
thread too.

https://codereview.chromium.org/2710823003/diff/420001/content/browser/render...
File content/browser/renderer_host/render_process_host_impl.cc (right):

https://codereview.chromium.org/2710823003/diff/420001/content/browser/render...
content/browser/renderer_host/render_process_host_impl.cc:1580:
resource_coordinator::mojom::EventType::ON_PROCESS_AUDIO_STARTED);
N.B. This notification is fine for what you're doing but in case it's useful
there's a separate audibility state that only triggers when the tab is playing
non-silent audio:
https://cs.chromium.org/chromium/src/content/browser/web_contents/web_content...
(we use this for policy decisions in the Blink scheduler)

https://codereview.chromium.org/2710823003/diff/420001/content/browser/render...
content/browser/renderer_host/render_process_host_impl.cc:2837: void
RenderProcessHostImpl::SetPolicy(
What's the latency of these updates? This is all in the browser so it should be
fairly low, but I assume there's still a task hop, right?

https://codereview.chromium.org/2710823003/diff/420001/services/resource_coor...
File services/resource_coordinator/coordination_unit.cc (right):

https://codereview.chromium.org/2710823003/diff/420001/services/resource_coor...
services/resource_coordinator/coordination_unit.cc:80: else if
(current_policy_->use_background_priority == background_priority)
I'm not sure how to enforce it, but we should probably encourage clients to
avoid sending redundant events if they can avoid it.

https://codereview.chromium.org/2710823003/diff/420001/services/resource_coor...
File services/resource_coordinator/public/cpp/resource_coordinator_interface.cc
(right):

https://codereview.chromium.org/2710823003/diff/420001/services/resource_coor...
services/resource_coordinator/public/cpp/resource_coordinator_interface.cc:28:
static int next_id = 0;
Do we need some locking here? I assume we'd eventually want to be able to access
the resource coordinator from any thread.

[oystein (OOO til 10th of July), 2017-04-07 16:08:27]

Description was changed from

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This CL depends on https://codereview.chromium.org/2798713002

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[oystein (OOO til 10th of July), 2017-05-18 18:37:51]

Description was changed from

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This CL depends on https://codereview.chromium.org/2798713002

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.

The service-side is especially hacked together; there's no
timeline-functionality right now, just some basic state bits. The DAG
functionality is also pretty quick'n'dirty, but functional.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This CL depends on https://codereview.chromium.org/2798713002

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.
==========

[oystein (OOO til 10th of July), 2017-05-30 22:09:32]

Description was changed from

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This CL depends on https://codereview.chromium.org/2798713002

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.
==========

to

==========
Global Resource Controller

NOTE: This CL is just a prototype and shouldn't actually land; it needs to be
split up and have tests added, after feedback.

GRC parent doc (internal only):
https://docs.google.com/document/d/1dx4KDbDFvP-GWwwrSPg8Gxx4kboIoPi8kDKTSXoTb...

This CL depends on https://codereview.chromium.org/2798713002

This thing should theoretically improve
https://bugs.chromium.org/p/chromium/issues/detail?id=693054 once the kinks are
worked out, by lowering process priority for background tabs even before they've
started painting.

Quick design tl;dr:

The basic Mojo interface is a CoordinationUnit. This can be created by the
browser process through a CoordinationUnitInterface, and can be duplicated on
demand from other processes (there's an example in the CL of Blink hooking up to
the frame-level CoordinationUnit). It can be used to send events through
(currently just basic enums with no args), and can be used to set a callback if
the client of the CoordinationUnit is interested in receiving resource policy
updates (as shown by RenderProcessHostImpl, which receives a should_background
policy).

There's CoordinationUnits hooked up to three different levels in this CL:
* WebContents-level
* Process-level
* Frame-level (Both Blink and browser-side; this is currently unused by the
prototype but there for demonstration purposes).

There's also a ResourceCoordinatorInterface helper class included, which wraps
around the CoordinationUnit for easier usage, and has functionality to set up
parent/child relationships between different units.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========