Not crazyily important to make this a Release Blocker, but I kinda want a script or a TPM search to remind us to look at this again in a month, so adding the blocker.  :-P

So far I don't know of any bugs resulting from the increased number of renderers on Caroline on R61

I've looked at UMA stats for caroline for 61 and 60

UMA reported Number of renderer processes:

Caroline 60 - https://uma.googleplex.com/p/chrome/histograms/?endDate=20170821&dayCount=7&histograms=Memory.RendererAll%2CMemory.RendererProcessCount%2CMemory.Total2&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C60%2Chw_class%2Ccnt%2CCAROLINE%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

renderer count  average             - 5
renderer count  50th percentile     - 4
renderer count  99th percentile     - 22

per-renderer memory average         - 104
per-renderer memory 50th percentile - 56
per-renderer memory 99th percentile - 671

# sum of all RSS, this overcounts shared memory
memory.total2 average               - 1852
memory.total2 50th percentile       - 1483
memory.total2 99th percentile       - 5936


Caroline 61 - https://uma.googleplex.com/p/chrome/histograms/?endDate=20170821&dayCount=7&histograms=Memory.RendererAll%2CMemory.RendererProcessCount%2CMemory.Total2&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C61%2Chw_class%2Ccnt%2CCAROLINE%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

renderer count   average            - 7
renderer count   50th percentile    - 5
renderer count   99th percentile    - 37

per-renderer memory average         - 80
per-renderer memory 50th percentile - 42
per-renderer memory 99th percentile - 452

# sum of all RSS, this overcounts shared memory
memory.total2 average               - 2041
memory.total2 50th percentile       - 1637
memory.total2 99th percentile       - 6554


Here's Kevin and Cave for comparison, where we didn't change the allowed number of renderers


Kevin 60 - https://uma.googleplex.com/p/chrome/histograms/?endDate=20170821&dayCount=7&histograms=Memory.RendererAll%2CMemory.RendererProcessCount%2CMemory.Total2&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C60%2Chw_class%2Ccnt%2CKEVIN%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

renderer count  average             - 5
renderer count  50th percentile     - 4
renderer count  99th percentile     - 25

per-renderer memory average         - 59
per-renderer memory 50th percentile - 25
per-renderer memory 99th percentile - 452

# sum of all RSS, this overcounts shared memory
memory.total2 average               - 1255
memory.total2 50th percentile       - 1101
memory.total2 99th percentile       - 3617


Kevin 61 - https://uma.googleplex.com/p/chrome/histograms/?endDate=20170821&dayCount=7&histograms=Memory.RendererAll%2CMemory.RendererProcessCount%2CMemory.Total2&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C61%2Chw_class%2Ccnt%2CKEVIN%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

renderer count   average         - 5
renderer count   50th percentile - 3
renderer count   99th percentile - 21

per-renderer memory average         - 53
per-renderer memory 50th percentile - 25
per-renderer memory 99th percentile - 409

# sum of all RSS, this overcounts shared memory
memory.total2 average               - 1146
memory.total2 50th percentile       - 903
memory.total2 99th percentile       - 3617


Cave also looks similar to Kevin:

Cave 60 - https://uma.googleplex.com/p/chrome/histograms/?endDate=20170821&dayCount=7&histograms=Memory.RendererAll%2CMemory.RendererProcessCount%2CMemory.Total2&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C60%2Chw_class%2Ccnt%2CCAVE%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial


renderer count   average            - 6
renderer count   50th percentile    - 5
renderer count   99th percentile    - 24

per-renderer memory average         - 105
per-renderer memory 50th percentile - 62
per-renderer memory 99th percentile - 671

# sum of all RSS, this overcounts shared memory
memory.total2 average               - 2070
memory.total2 50th percentile       - 1808
memory.total2 99th percentile       - 6554


Cave 61 - https://uma.googleplex.com/p/chrome/histograms/?endDate=20170821&dayCount=7&histograms=Memory.RendererAll%2CMemory.RendererProcessCount%2CMemory.Total2&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C61%2Chw_class%2Ccnt%2CCAVE%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

renderer count   average            - 6
renderer count   50th percentile    - 5
renderer count   99th percentile    - 22


per-renderer memory average         - 98
per-renderer memory 50th percentile - 56
per-renderer memory 99th percentile - 608

# sum of all RSS, this overcounts shared memory
memory.total2 average               - 1961
memory.total2 50th percentile       - 1637
memory.total2 99th percentile       - 5936


So it looks like we do see an increase in the average and 99th percentile number of renderers on Caroline, and some increase in memory usage as well, but it's a little hard to tell how much exactly because the Total2 overcounts on shared memory, but may be as much as 7-8% 

All of the metrics for the size of a renderer process went down substantially on Caroline - so the effect was measurable,  though it looks like only the heaviest users would see much difference, and it should help them more since discarding will be more effective.

Are we planning to do anything here in 62? If this blocks beta, we are running low on time. 

Should this punt to 63?

yeah let's move to 63

so I've continued to monitor the stats for caroline on 61 beta -- seems similar to what we saw on 60 beta, so I don't think there's any adverse effects here -- let's change this to be on all boards.

Here is the histogram comparing number of discards:

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=506af54788025c7a82354788d57e73c2

It shows R61 has fewer discards than R60, which is a good sign meaning more memory can be freed by discarding fewer tabs due to separate renderer processes.

Just a reminder that this is an M63 beta blocker. M63 goes beta 10/26. 

Yeah -- The data was a bit noisy when I looked at it because of beta channel, I'm working on a change to Chrome instead of doing it in session manager now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8048987c7f5fa6f31d66930b7b879c2d33cc1a60

commit 8048987c7f5fa6f31d66930b7b879c2d33cc1a60
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Wed Oct 25 04:38:36 2017

Raise renderer process limit on Chrome OS for all boards

After running an experiment on Caroline with the renderer process
limit raised to 100, we saw a decrease in the overall number of tab
discards and no increase in the number of kernel OOM kills, so this
seems like a better policy that makes the tab discarder more
effective.

Bug:  743170 
Change-Id: I83e1ee996e028608dc906896e15cc60afe512e5b
Reviewed-on: https://chromium-review.googlesource.com/729495
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511372}
[modify] https://crrev.com/8048987c7f5fa6f31d66930b7b879c2d33cc1a60/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/8048987c7f5fa6f31d66930b7b879c2d33cc1a60/content/browser/renderer_host/render_process_host_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/22bdb591c3fcc71f291aa178547ccaa68fe69030

commit 22bdb591c3fcc71f291aa178547ccaa68fe69030
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Fri Oct 27 00:08:20 2017

Raise renderer process limit on Chrome OS for all boards

After running an experiment on Caroline with the renderer process
limit raised to 100, we saw a decrease in the overall number of tab
discards and no increase in the number of kernel OOM kills, so this
seems like a better policy that makes the tab discarder more
effective.

TBR=sonnyrao@chromium.org

(cherry picked from commit 8048987c7f5fa6f31d66930b7b879c2d33cc1a60)

Bug:  743170 
Change-Id: I83e1ee996e028608dc906896e15cc60afe512e5b
Reviewed-on: https://chromium-review.googlesource.com/729495
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511372}
Reviewed-on: https://chromium-review.googlesource.com/741034
Cr-Commit-Position: refs/branch-heads/3239@{#256}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/22bdb591c3fcc71f291aa178547ccaa68fe69030/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/22bdb591c3fcc71f291aa178547ccaa68fe69030/content/browser/renderer_host/render_process_host_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e2429af625c284d1e03039c1734aff23abd83ff

commit 0e2429af625c284d1e03039c1734aff23abd83ff
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Fri Oct 27 20:59:13 2017

Fix naming of RenderProcessHostUnitTest for Android and Chrome OS

Previously we raised the limit of renderer processes on Chrome OS to
be much higher and then had to change Chrome OS builds to use the same
unit test as Android -- However, I neglected to properly rename that
test, so this is fixing that.

Bug:  743170 
Change-Id: I59b2ba5781ebb17362f0c8876722be109fe3d438
Reviewed-on: https://chromium-review.googlesource.com/741069
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512267}
[modify] https://crrev.com/0e2429af625c284d1e03039c1734aff23abd83ff/content/browser/renderer_host/render_process_host_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/a265697b8247ae18a8263741c6bb18352da6ca98

commit a265697b8247ae18a8263741c6bb18352da6ca98
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Sun Oct 29 01:08:48 2017

login: remove flag to add more renderer processes on Caroline

We've added this flag to Chrome for all devices now, so there's no
need to have this special case for Caroline anymore.

BUG= chromium:743170 
TEST=build/boot caroline, check for lack of --max-renderers=100 in Chrome
 command line

Change-Id: Ib89cb69cd99e9828e3f1bf59fd2360eba5e692a2
Reviewed-on: https://chromium-review.googlesource.com/737511
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/a265697b8247ae18a8263741c6bb18352da6ca98/login_manager/chrome_setup.cc

Do you think the hard coded 100 value will make sense in the far future? Will it need to be infrequently bumped up as the minimum RAM in supported devices go up?

it's usually hard to tell what will happen in the far future :-) 

It certainly could be an issue -- though based on the UMA data at the time, a very very very small fraction of users were approaching that number -- like 99.9th percentile.

Here's some more current data for Caroline on R66:

https://uma.googleplex.com/p/chrome/histograms/?endDate=latest&dayCount=7&histograms=Memory.RendererProcessCount&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cmilestone%2Ceq%2C66%2Chw_class%2Ccnt%2CCAROLINE%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial


renderer count   average         - 5
renderer count   50th percentile - 3
renderer count   99th percentile - 32

So the 99th percentile has gone slightly down vs when I looked on R61 (it was 37), but it's not many users and we're still really far from 100


I was leaning towards just making it unlimited but people wanted some kind of limit.