Web lists-archives.com

Re: Electrolysis




Mark12547 wrote on 10/28/2017 4:51 PM:
I'll attempt to answer some (but probably not all) of the questions.

In article <ObudnUGffuXicXfEnZ2dnUU7-TvNnZ2d@xxxxxxxxxxx>,
jbbrus@xxxxxxxxxxx says...
1. In Options-General, what does "Content process limit" actually mean?
For example, mine is set to 4 but I see as many as 7 FF processes in the
Window's task manager.

The "Content process limit" limits the number of Firefox content
processes. Roughly, you can think of a "content process" as a process
that interprets and renders a web page, essentially what renders the
content of a tab or multiple tabs.

If working on multiple tabs, a content process may delay rendering one
tab while it is busy working on another tab. So a complicated page or a
page that is JavaScript-heavy may cause delays in rendering other tabs.
(The long-term plan is to use multiple simultaneous threads to allow
multiple pages to be worked on simultaneously by the same process, but
as of today a process can work on only one page at a time.)

If using multiple content processes, if a content process is busy with
one web page / tab, it won't hold up another content process assigned to
other tab(s).

I have a web page I frequent several times a week that takes 35 seconds
in Firefox Nightly to render, and rather than hold up other tabs for
that 35 seconds, I use dom.ipc.processCount = 10 so I can use 9 other
content processes for up to 9 other tabs while one of those content
processes is busy with that one long-time-loading page. (If I have a
smaller limit on content processes than I have active tabs, some content
processes will handle two or more tabs, running the risk that I might
want to interact with a tab when that tab's process is busy rendering
that 35-seconds-to-load page.)

If a content process crashes, only the tab(s) controlled by that content
process crash, while the rest of Firefox should be able to keep on
running.

Those are content processes: rendering one or more tabs.

There are other processes Firefox uses, but are _not_ content processes.

The main/UI process. When you start Firefox, it starts the main/UI
process, which launches and coordinates the other processes, and which
also runs the user interface.

The gpu process. If using hardware acceleration, a gpu process is
launched to interact with the gpu. If the gpu process crashes, Firefox
is suppose to fall back to non-gpu code.

If using Flash, Firefox will launch a process (formerly called a
"container") to run Flash, so if Flash crashes it doesn't crash other
parts of Firefox.

More recently, Firefox has been using a process for running extensions.
This is a "sandbox" feature that further isolates extensions from the
rest of Firefox, working only with WebExtensions.

Since "Content process limit" only limits the number of content
processes (you can have fewer if you have fewer tabs open), the other
Firefox processes are handling other things (main/UI, gpu, Flash
container, extensions sandbox).

Each process can have one or more threads, but the operating system sets
permissions, resources, handles at the process level, but schedules
execution of instructions at the thread level. Theoretically, a process
can have multiple threads ready to run and the operating system would
schedule those threads in available cores of the CPU. However, because
of the way the Gecko engine was originally written, much of the content
process has to run as if there were only one core (the rewrite in Rust
should eventually remove this restriction), so to render multiple pages
at the same time one can use multiple content processes, each content
process using a slice of a different core at the same time, the net
effect is that multiple content processes can use multiple cores to
simultaneously render multiple web pages. But if there are more threads
ready to use the CPU than there are cores, the operating system will
first run those threads with a higher priority and, when there are more
threads ready to run at the same priority than there are available
cores, will time-slice between them. (The exact details may vary between
operating systems.) In addition to rendering, the main/UI process will
also use CPU cycles to display the status of the tab (the "throbber" for
loading a page, for example), and give you tab-level control (closing a
tab, opening a new tab, running an internal page like
about:performance).

I know only a little bit about the Intel hyper-threading models and I
doubt that I could provide anything meaningful there, except to state
what the CPU documentation means by hyper-threading doesn't mean the
same thing as a thread when speaking of a process; to the program the
hyper-threading (when enabled) just looks like more cores.

Thanks for the information. In Intel land most modern CPU cores actually implement two instruction executing sub-cores that share memory management and clock (as I understand it). These sub cores are the hyper-thread execution sites. The ACPI specification provides a hardware description and driver (programming) language that most compliant OS can interpret at run time. Descriptors are provided to specify "closeness" of CPU's. So the sub-cores of one core are closer than sub-cores of different cores. The OS can use this information, in theory, to assign processes that share a lot of references to closer CPU's. In this sentence, CPU means sub core.
--
Jeff Barnett

_______________________________________________
general mailing list
general@xxxxxxxxxxxxxxxxx
https://lists.mozilla.org/listinfo/general