Currently the logic for computing the maximum number of renderer processes on Chrome is shared amongst all operating systems (except Android) and for a 64-bit system with 4 GB of memory that calculation maxes out at around 34 renderers. 

Extensions typically get their own renderer up to 1/3 of all possible renderers, so this leaves something like 23 renderers available for general tabs or applications.  

We're seeing in feedback reports that users are seeing OOM kills or jank despite the fact that the tab discarder was invoked prior to these situations and usually the issue is that the discarder tried to kill a tab that was in a shared renderer and over estimated the amount of memory freed. Unfortunately there's not a good way to improve this estimate right now.

Increasing the number of allowed renderers will allow the discarder to be more effective in these cases where the users have a lot of tabs, and will lead to some increase in overall memory consumption and tab discarding but should improve user experience otherwise due to less jank.

I've run experiments using the telemetry tab switching test on a Caroline with repeated page sets to add a lot of memory pressure.  The test opens a set of 25 tabs N times and then cycles through them.  It's a very stressful test because it has worst case behavior, but the discarder also should be able to handle it well because everything is done in perfect LRU order.

With the current default  number of renderers I'm able to cause a kernel OOM kill reliably with 6 repeated page sets, but when I increase the number of allowed renderers I'm not able to cause a kernel OOM at all even with 10 repeated page sets.