Electrolysis

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Electrolysis

Jeff Barnett
I subscribed to mozilla.dev.tech.electrolysis on news.mozilla.org. I've
seen no old or new messages in that group. Is there another source/group
that might discuss the multiprocessing aspects of FF? I have some
questions and was hoping for a place to "lurk" and see what information
I might pick up. TIA
--
Jeff Barnett
_______________________________________________
general mailing list
[hidden email]
https://lists.mozilla.org/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Electrolysis

WaltS48-5
On 10/19/17 3:22 PM, Jeff Barnett wrote:
> I subscribed to mozilla.dev.tech.electrolysis on news.mozilla.org. I've
> seen no old or new messages in that group. Is there another source/group
> that might discuss the multiprocessing aspects of FF? I have some
> questions and was hoping for a place to "lurk" and see what information
> I might pick up. TIA

I just subscribed to test the group and got 165 messages. The last one
is dated 4/22/16, but when I go back all the messages are deleted
because of my retention settings.

You could review the IRC logs here
<https://mozilla.logbot.info/e10s/20171019> and or join the channel on
Mozilla IRC.

Review meeting notes here
<https://wiki.mozilla.org/Electrolysis/Meetings> Last one was in 2016.

Review status reports here
<https://wiki.mozilla.org/Electrolysis#Weekly_Status_Reports> Some from
2017 there.

Read the MDN articles
<https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox>

Search Discourse for e10s and Electrolysis. <https://discourse.mozilla.org/>

Or ask questions here. Some of us may be able to answer them, or not.

--
Go Bills, Steelers, Pitt, Pens and Sabres!
Coexist <https://www.coexist.org/>
National Popular Vote <http://www.nationalpopularvote.com/>
Ubuntu 16.04LTS - Unity Desktop
_______________________________________________
general mailing list
[hidden email]
https://lists.mozilla.org/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Electrolysis

Jeff Barnett
WaltS48 wrote on 10/19/2017 1:47 PM:

> On 10/19/17 3:22 PM, Jeff Barnett wrote:
>> I subscribed to mozilla.dev.tech.electrolysis on news.mozilla.org.
>> I've seen no old or new messages in that group. Is there another
>> source/group that might discuss the multiprocessing aspects of FF? I
>> have some questions and was hoping for a place to "lurk" and see what
>> information I might pick up. TIA
>
> I just subscribed to test the group and got 165 messages. The last one
> is dated 4/22/16, but when I go back all the messages are deleted
> because of my retention settings.
>
> You could review the IRC logs here
> <https://mozilla.logbot.info/e10s/20171019> and or join the channel on
> Mozilla IRC.
>
> Review meeting notes here
> <https://wiki.mozilla.org/Electrolysis/Meetings> Last one was in 2016.
>
> Review status reports here
> <https://wiki.mozilla.org/Electrolysis#Weekly_Status_Reports> Some from
> 2017 there.
>
> Read the MDN articles
> <https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox>
>
> Search Discourse for e10s and Electrolysis.
> <https://discourse.mozilla.org/>
>
> Or ask questions here. Some of us may be able to answer them, or not.

Thank you for the offer, it's appreciated. First some information about
my setup: Win 7 Pro SP1 64-bit; Intel 6 core processor with
hyper-threading enabled; FF 56.0.1 64 bit.

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.

2. If "process" actually means "processor" above, are we counting CPU
cores or hyper-thread cores? In other words could my spec of 4 mean 4
cores and, thus, 8 hyper-thread cores? Or are we actually talking of
processes according to windows that might or might not run on different
pieces of hardware? (I'm making up the term "hyper-thread core" but
don't know what to use instead.)

3. What type of synchronization primitives provide critical sections to
access shared structures such as the cache or book marks?

4. What disciplines are used to avoid deadly embrace, e.g., strict
semaphore locking order when a process/thread must hold more than one?

5. In Mozilla terminology are threads something different than processes
viz a viz your semantic execution model? If, so what is/are the differences?

Any insight would be most appreciated. By the way, I'm asking out of
simple curiosity there is no urgency for this information.
--
Jeff Barnett
_______________________________________________
general mailing list
[hidden email]
https://lists.mozilla.org/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Electrolysis

Mark12547
I'll attempt to answer some (but probably not all) of the questions.

In article <[hidden email]>,
[hidden email] 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.
_______________________________________________
general mailing list
[hidden email]
https://lists.mozilla.org/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: Electrolysis

Jeff Barnett
Mark12547 wrote on 10/28/2017 4:51 PM:

> I'll attempt to answer some (but probably not all) of the questions.
>
> In article <[hidden email]>,
> [hidden email] 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
[hidden email]
https://lists.mozilla.org/listinfo/general