Single-core CPU gets bogged down with multiple processes though there should be only one

RESOLVED DUPLICATE of bug 1399962

Status

()

Core
DOM: Content Processes
RESOLVED DUPLICATE of bug 1399962
a month ago
28 days ago

People

(Reporter: ddurst, Unassigned)

Tracking

57 Branch
Unspecified
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a month ago
I have a Win10 machine with a single-core CPU, and at seemingly random times on some sites, it slows to a crawl. This first happened with 4GB RAM, and still happens with 8GB RAM.

Profile investigation has yielded 4 discrete processes that are struggling in scheduling (courtesy of mconley) on some sites, sometimes.

The question is why? The machine has dom.ipc.processCount set to 1, but dom.ipc.processCount.web is 4.

I've set dom.ipc.processCount.web to "" and 1, but any subsequent restart of Firefox resets it to 4, modified by what I don't know.

Is there some other setting I should be looking at to explain this? Is this expected? This is a baseline Dell machine (Inspiron 15 5000 series with an i3 chip), so it seems like it's probably a common scenario.
(Reporter)

Updated

a month ago
Summary: Single-core CPU gets bogged down with multiple processes thought there should be only one → Single-core CPU gets bogged down with multiple processes though there should be only one
Hey felipe, any idea what could be going on here?
Flags: needinfo?(felipc)
I'm gonna relay it to Blake
Flags: needinfo?(felipc) → needinfo?(mrbkap)
(In reply to David Durst [:ddurst] from comment #0)
> I have a Win10 machine with a single-core CPU, and at seemingly random times
> on some sites, it slows to a crawl. This first happened with 4GB RAM, and
> still happens with 8GB RAM.

Bug 1399962 will track throttling back to 1 content process on machines with too few cores.

> The question is why? The machine has dom.ipc.processCount set to 1, but
> dom.ipc.processCount.web is 4.
> 
> I've set dom.ipc.processCount.web to "" and 1, but any subsequent restart of
> Firefox resets it to 4, modified by what I don't know.

This is due to the awkward way that the rollout happened. Unfortunately, 1 content process is the "default" value, so the e10srollout extension happily sets the override value (the .web pref) to 4. In Firefox 58, we correctly set dom.ipc.processCount to its real default value of 4, so setting it to 1 will effectively disable e10s-multi.

Alternatively, setting dom.ipc.multiOptOut to the integer 1 will disable multiple content processes. The final way of truly disabling multi would be to set dom.ipc.processCount to 0. We will detect that as a "user set" value and we normalize its value to 1 before using it [1]. It's a bit hacky, but it works.

I'm going to dupe this bug to bug 1399962 since that'll fix the performance problem and the pref stuff is unfortunate baggage that is going to go away once Firefox 58 is pushed to everybody.

[1] https://searchfox.org/mozilla-central/rev/ac39cffaabad4b31685c8792f9e79812a927ecee/toolkit/xre/nsAppRunner.cpp#5243-5244
Status: NEW → RESOLVED
Last Resolved: 28 days ago
Flags: needinfo?(mrbkap)
Resolution: --- → DUPLICATE
Duplicate of bug: 1399962
You need to log in before you can comment on or make changes to this bug.