I see a metric called kIdleSecondsBeforeExit = 10 * 60. I am guessing the threads are kept around for 10 minutes:
https://chromium.googlesource.com/chromium/src/+/master/base/threading/worker_pool_posix.cc#31

I wonder if this should be reduced or at least be platform dependent. I see that it uses the same in android as well.
This was set in https://chromium.googlesource.com/chromium/src/+/250103f6249e1f19ab14ff69f4356fee56833af8 and maybe not optimized for android?

I wonder if this can be reduced for linux too.

I'm no longer working on Chromium. I've removed myself from the cc list. Some comments though.

The original constant was set as a magic number when we were porting Chromium to Linux. It was meant to mimic the Windows system thread pool, which IIRC, kept idle threads around for minutes too. This was more important for Windows where thread creation is costlier.

Reaping worker threads more aggressively seems reasonable to me. Cheers.

+Lei who reviewed the last CL in this file.
WDYT?

+some folks working on simplify task management to see whether they have some insight.

I am not sure about the performance, but the malloc usage reduces by 10% (private_dirty by 6-7%) in benchmarks if the idle thread is exited in 3 secs instead of 600. See results of running a page cycler, better if I run it more number of times since the malloc usage usually keeps increasing.
Check the metrics "malloc_browser" and "private_dirty_browser".

Deleted: results.html 868 KB

results.html 868 KB View Download

It seems 1_run is better, but 5_run is worse. Also can you get the data from an Android device too? Thanks.

Some speculation: It would be surprising to me if the worker threads inherently allocated this memory. The problem might not be so much that the threads are running (it would be good if they go away sooner) but rather that when the tab is closed, resources are not reclaimed in a timely fashion and should be decoupled from the thread lifetime.

Agreed with Rob that the issue seems to be that the memory and thread lifetime should be decoupled. However good news is we're refactoring the worker task model in Chrome right now and WorkerPool will be one of the first candidates for deprecation. If the issue is improper memory vs thread lifetime though, the new framework may also not be able to do much about that (besides having control on unused thread termination).

@klobag I think you got confused since the one with 3 seconds comes first. Killing the threads aggressively saves some memory.

Yes, I understand that the memory allocated itself is not fully coupled with the thread's lifetime. Investigating more I found that the worker threads were created for network certificate verification. But there is already a bug filed for this  crbug.com/593486 .

Yes, I think the main problem left here is to termite the unused threads. Especially on android which is good even if it just saves few hundred Kib needed to keep an idle thread alive. wdyt?

Could you please share a design doc or bug for the new worker thread model and timeline?
I do not fully understand how the unused threads can be terminated in the current model. Can it be?

Design Doc (chromium.org): https://docs.google.com/a/chromium.org/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa5k/edit?usp=sharing

Agreed that cleaning up an idle thread would be good, but as you say it's inherently only a few KiB. The larger issue here is coupling of the memory lifetime with the thread. The worker threads may be reused for other purposes, and so this separate cleanup should happen  independent on the thread lifetime.

This bug is available, yet hasn't been updated in >180 days. Dropping the priority.

WorkerPool is going away in favor of TaskScheduler (which does properly reclaim inactive threads).

We are working on the last few edge cases right now and expect full deprecation this quarter as such efforts on WorkerPool are not worth it.