On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote:
On 11 Jul 2018, at 10:10 pm, Kris Maglione <kmagli...@mozilla.com> wrote:
It looks like it will be helpful, but unfortunately won't give us the 2MB
simple arithmetic would suggest. On Windows, at least, (and probably
elsewhere, but need to confirm) thread stacks are lazily committed, so as long
as the decoders aren't used in a process, the overhead is probably closer to
25KB per thread.
I haven’t looked much in details, not being an expert on this and having just
finished watching the world cup…
A quick glance at the code gives me:
On mac/linux using pthread:
when a thread is created, the stack size is set using pthread_attr_setstacksize
https://searchfox.org/mozilla-central/source/nsprpub/pr/src/pthreads/ptthread.c#355
On Linux, the man page is clear:
"The stack size attribute determines the minimum size (in bytes) that will be
allocated for threads created using the thread attributes object attr.”
Right, but allocation size doesn't imply that the memory is committed, just that
it's mapped. In general, anonymous mapped memory isn't actually committed (and
therefore doesn't become part of the process's USS) until it's touched.
On Windows:
https://searchfox.org/mozilla-central/source/nsprpub/pr/src/md/windows/w95thred.c#151
the thread is created with STACK_SIZE_PARAM_IS_A_RESERVATION flag set. This
will allocate the memory immediately.
Allocate, yes, but not commit. That flag is actually what ensures that our
Windows thread stacks don't consume system memory until they're actually
touched.
The saving I was mentioning earlier isn’t just due to media decoder threadpool
thread stack no longer needing to be that big, but that all other threadpools
can be reduced too. Threadpools aren’t used only when playing a video/audio
file.
Reducing thread pool sizes would certainly be helpful. One unfortunate
side-effect of large thread pools is that, even with lazy commit thread stacks,
the more threads you run code on, the more stacks wind up with committed pages.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
