On Thursday, 23 March 2017 01:01:16 UTC, Nicholas Nethercote wrote: > Do we have a clear definition of "content process"? I.e. does/will it > include: > > - GMP processes (no?) > - GPU process (probably not?) > - file:// URL processes (probably should?) > - Web Extensions processes (probably should?) > - ServiceWorker processes (probably should?)
Each content process type (remote type) has its own pool of processes. Remote types at the moment are: web (the normal content process), file, extension and webLargeAllocation. GMP and GPU are their own GeckoProcessType. (I'm not sure how the ServiceWorker one fits into this.) Currently the pref dom.ipc.processCount acts as the default if dom.ipc.processCount.<remote type> is not set. (Mainly because this pref was already being used by a number of people, perhaps it should just have been left as a fallback for dom.ipc.processCount.web) Current pref settings: * dom.ipc.processCount : 1 (Nightly 4) * dom.ipc.processCount.extension : 1 * dom.ipc.processCount.webLargeAllocation : 10 So, on Nightly the web and file processes will both use up to 4 processes. The file:// URL process is probably a fairly special case (although I don't have any stats on its usage), so we should probably add a specific setting of 1 for that. Maybe that 4 should be set on dom.ipc.processCount.web instead. There has also been talk of setting an overall maximum although you would always have to allow at least 1 of each to start, even if we were at the maximum. Cheers, Bob > Thanks. > > Nick > > On Thu, Mar 23, 2017 at 10:45 AM, Blake Kaplan <mrb...@mozilla.com> wrote: > > > Hello all, > > > > As some of you might have noticed, we are now defaulting to 4 content > > processes on Nightly builds! We're continuing to collect data and > > planning on running experiments with different numbers of processes to > > generate more data and allow us to fine-tune our defaults and > > strategies for process allocation. > > > > As part of our effort to enable e10s-multi on Nightly, we disabled a > > few tests that were misbehaving. We've re-enabled most of them and are > > on track to finish re-enabling them (after verifying that the problem > > was in the test and not the underlying code). > > > > As we get to the end of that effort, I'd like to ask everybody to > > think about any areas that they feel are not tested with multiple > > content processes that should be. Obviously, as we find regressions > > related to multiple content processes we'll add regression tests, but > > I would like to avoid having any last-minute panics over missing > > tests. > > > > Thanks. > > -- > > Blake > > _______________________________________________ > > firefox-dev mailing list > > firefox-...@mozilla.org > > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
