1475091 - Dropping rayon thread pool when a content process is inactive?

Status: NEW

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Xidorn Quan [:xidorn] UTC+11]

We spawn several style threads (min(6, max(1, no. of cores * 3 / 4))) for each process, and each of the thread has 256KB stack,

Maybe we can drop those threads and release their stack when a content process becomes inactive, and recreate the pool in tab switching (maybe tab warming would help)?

Comment 1

[Bobby Holley (:bholley)]

Yeah, this seems like a good idea. Most of the time these stacks don't get deep, except occasionally during invalidation handling, and also stuff like bug 1395708#c15. Dynamically deactivating the thread pool is probably smart.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

TabGroup::HasOnlyThrottableTabs may or may not be useful here.
There should probably be some notification telling when process is totally in background or not.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

ProcessPriorityManager::TabActivityChanged might also be useful: https://searchfox.org/mozilla-central/rev/46292b1212d2d61d7b5a7df184406774727085b8/dom/ipc/TabParent.cpp#2873

Comment 4

[Eric Rahm [:erahm]]

At a minimum we're looking at 25K per thread, assuming 6 threads that's 150K. Bug 1395708, comment 15 saw something more like 100K of committed stack space, so that' would give us 600K. For an optimistic guess I'm putting this in the 500K range.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #4)
> At a minimum we're looking at 25K per thread, assuming 6 threads that's
> 150K. Bug 1395708, comment 15 saw something more like 100K of committed
> stack space, so that' would give us 600K. For an optimistic guess I'm
> putting this in the 500K range.

That bug was specifically about an infrequently-used Cocoa color API that allocated an enormous amount of stack space, so I'm skeptical that we end up committing that much in practice, especially on average. I think 250k is probably a more likely estimate.

Comment 6

[Eric Rahm [:erahm]]

(In reply to Bobby Holley (:bholley) from comment #5)
> That bug was specifically about an infrequently-used Cocoa color API that
> allocated an enormous amount of stack space, so I'm skeptical that we end up
> committing that much in practice, especially on average. I think 250k is
> probably a more likely estimate.

Makes sense, updated.

Comment 7

[Eric Rahm [:erahm]]

One thing we need to note here is that we currently can't destroy per-thread arenas (bug 1364359), so we'd need to do something to hang onto a reference and reuse the existing ones.