Firefox Still Working Towards Multi-Process Support

[liam]

I'll have to check to see what happens when you have two Firefox windows open or if another window is of their private nature. You'd think they'd be separate processes not hanging off the same application. Obviously Gecko must be multi process.

You'd think that, but I dont think it is. I THINK that is one of the reasons behind the servo project.

[liam]

Just because something is multi-threaded, it doesn't mean it is inherently memory consuming. But, this is firefox we're talking about here, so yeah, it'll probably be a disaster.

Maybe what would be the most ideal is a separate process per group. I know most people don't use groups in firefox, but doing this would be a lot more reasonable in terms of performance vs memory consumption vs dependability.

Firefox is great with memory. What tests are you looking at?
Going with processes will make it easier to reclaim memory after tab shutdown.

https://areweslimyet.com/

[liam]

I was reading about this [elsewhere] a couple of days ago....

I cannot fscking wait for this feature. It is super easy to choke firefox on linux-rt, particularly, i can choke it quite easily if using mutexes (as opposed to semaphoes) in the nvidia driver... Specifically, when using multiple videos - streaming in multiple tabs.... You can easily halt firefox, the interface becomes non-interactive, etc, until it's done loading all tabs/videos.. Having some separation here / making it multi-process would solve this issue / have better latency, guarantee of service, etc.

Glad you popped up. DId you catch the article on lwn about the deadline scheduler FINALLY making it to linus' branch? I'm not sure how useful it will be for you right now since the process needs to know its worst case exec time, but I'm wasn't sure if that was already well known for your work.

[mrugiero]

You could split the threads:
y GUI threads
x rendering, worker threads.
- separate threads for visible and non visible tab.
Each window should get it's own GUI threads until some maximum number of threads, say number of CPU cores, is reached.
Each visible tab should get it's own thread until some maximum number of threads, say number of CPU cores, is reached. This configuration minimizes latency and maximizes cpu resources while not inefficiently using cpu cores the memory by avoiding tons of threads.
.
Then also a number of threads for non visible tabs, say number of CPU cores to maximize performance and computing resources.
As long as the number of non visible tabs are below the number of CPU cores, then each non visible tab gets it's own thread.

This allows good latency, performance, allocation of CPU resources while not making tons of threads that are not needed.

There is an extra benefit on real memory use I haven't thought of. IIUC, swapping works per process, so having several threads helps you avoid the performance impact of having to many open tabs that you are not actively using, as their process can be swapped out while you get into main memory your currently hot tabs. I'm not sure if you can do this with threads. Paying ~10MB for offloading several hundreds to disk may be a nice benefit. Although I believe Firefox already cleans the page cache when low on memory.

Glad you popped up. DId you catch the article on lwn about the deadline scheduler FINALLY making it to linus' branch? I'm not sure how useful it will be for you right now since the process needs to know its worst case exec time, but I'm wasn't sure if that was already well known for your work.

If you talk about RT OSes, you always need to know the worst case exec time, as you need to guarantee a maximum time for everything. That's the main characteristic of any RO OS.

[bwat47]

"notably missing from the threading party has been Mozilla Firefox"

Just as a clarification, Firefox is multithreaded. All the threads are just owned by one process.

Its still not multithreaded enough though, the UI chugs a lot more under load than google chrome. It still doesn't even have off-the-main-thread compositing enabled on windows and linux.

I love firefox and still use it as my main browser, but multithreading and UI responsive are very weak points for it still. Chrome is very far ahead of it in this area, it has a fully multi-process architecure, threaded compositing by default, and a fully hardware accelerated UI which will appear in chrome 33.

[MWisBest]

I was reading about this [elsewhere] a couple of days ago....

I cannot fscking wait for this feature. It is super easy to choke firefox on linux-rt, particularly, i can choke it quite easily if using mutexes (as opposed to semaphoes) in the nvidia driver... Specifically, when using multiple videos - streaming in multiple tabs.... You can easily halt firefox, the interface becomes non-interactive, etc, until it's done loading all tabs/videos.. Having some separation here / making it multi-process would solve this issue / have better latency, guarantee of service, etc.

I think the video streaming issue is something to do with Flash, Flash being in a separate process, and X. See if it's any different with HTML5 video.

[DeepDayze]

Yes it does. On Linux the flash-plugin being taxed heavily will bring it down without much hesitation.

Ditto

Flash is the most problematic plugin on FF on any platform (even Windows!), followed by java.

[liam]

If you talk about RT OSes, you always need to know the worst case exec time, as you need to guarantee a maximum time for everything. That's the main characteristic of any RO OS.

RT processes were mentioned in the article as being different. That is rt processes use priories priorities rather than deadlines. Hence this is a much different type of scheduler (and more sophisticated) than than simply looking at which process has the highest priority and wants to run.
Since we aren't taking about hard real-time systems (that is ones that are very much appliance like, and run very few processes) we don't necessarily know ahead of time those worst case times would be. The article didn't go into that aspect, unfortunately.

[Apteryx]

Phoronix: Firefox Still Working Towards Multi-Process Support

[...] enabling a Firefox preference setting it's possible to ruin in a multi-process mode. [...]

http://www.phoronix.com/vr.php?view=MTUzNTY

I guess it's not ready for prime time