The only issues I'm aware of with dom.ipc.processCount > 1 are: 1. The devtools "Browser Content Toolbox" doesn't work. 2. Some printing related stuff doesn't work. 3. There's a theoretical issue where plugins can hang when processCount > 1 and when more than one plugin is running. The first two should be easy to fix. The last one is harder. I think the easiest fix would be to run all plugins from the same plugin process.
I remember the issue Ted mentioned, and it was fixed by bug 567058. One major issue I've noticed with the spinner is that the content process doesn't get much CPU time when the system is under heavy load, at least under Linux. I think we're probably not doing a good job or respecting Linux's interactivity heuristic or something. The main process seems to get scheduled more frequently, so non-e10s performs better in that situation. Other OSs probably have similar issues. Increasing processCount doesn't help with this problem. The main reason we haven't increased processCount is because we want to ship as soon as possible and this seems like the way to do it. I guess it really comes down to which is easier: - getting content process memory usage low enough that we can increase processCount, - or getting performance of processCount=1 good enough that we're at parity with non-e10s. I suspect the latter will be easier, but we'll see. We haven't focused much on performance yet. Regarding process-per-core or process-per-domain or whatever, I just want to point out that responsiveness will improve even beyond process-per-core. So I do think we're going to want more than just 4 or 8 content processes. We're just going to have to work really hard on the memory usage. I've noticed a lot of waste for really small content processes. One of my content processes (for mxr) looks like this right now: explicit 50MB, heap-overhead 19MB, js-non-window 14MB, heap-unclassified 12MB. The actual window is only 0.89 MB. -Bill On Tue, May 5, 2015 at 8:41 AM, Mike Conley <mcon...@mozilla.com> wrote: > >> Is there a more detailed description of what the issues with multiple> > content processes are that e10s itself doesn't suffer from? > > I'm interpreting this as, "What are the problems with multiple content > processes that single process does not have, from the user's perspective?" > > This is mostly unknown, simply because dom.ipc.processCount > 1 is not > well tested. Most (if not all) e10s tests test a single content process. > As a team, when a bug is filed and we see that it's only reproducible > with dom.ipc.processCount > 1, the priority immediately drops, because > we're just not focusing on it. > > So the issues with dom.ipc.processCount are mostly unknown - although a > few have been filed: > > https://bugzilla.mozilla.org/buglist.cgi?quicksearch=processCount&list_id=12230722 > > >> One of the extremely common cases where I used to get the spinner was> > when my system was under load (outside of Firefox.) I doubt that we're> > going to be able to fix anything in our code to prevent showing the> > spinner in such circumstances. > > Yes, I experience that too - I often see the spinner when I have many > tabs open and I'm doing a build in the background. > > I think it's worth diving in here and investigating what is occurring in > that case. I have my suspicions that > https://bugzilla.mozilla.org/show_bug.cgi?id=1161166 is a big culprit on > OS X, but have nothing but profiles to back that up. My own experience > is that the spinner is far more prevalent in the many-tabs-and-build > case on OS X than on other platforms, which makes me suspect that we're > just doing something wrong somewhere - with bug 1161166 being my top > suspect. > > > Another such common case would be one> CPU hungry tab. > > I think this falls more under the domain of UX. With single-process > Firefox, the whole browser locks up, and we (usually) show a modal > dialog asking the user if they want to stop the script. In other cases, > we just jank and fail to draw frames until the process is ready. > > With a content process, the UI remains responsive, but we get this > bigass spinner. That's not an amazing trade-off - it's much uglier and > louder, IMO, than the whole browser locking up. The big spinner was just > an animation that we tossed in so that it was clear that a frame was not > ready (and to avoid just painting random video memory), but I should > emphasize that it was never meant to ship. > > If we ship the current appearance of the spinner to our release > population... it would mean that my heels have been ground down to nubs, > because I will fight tooth and nail to prevent that from happening. I > suspect UX feels the same. > > So for the case where the content process is being blocked by heavy > content, we might need to find better techniques to communicate to the > user what's going on and to give them options. I suspect / hope that bug > 1106527 will carry that work. > > Here's what I know: > > 1) Folks are reporting that they _never_ see the spinner when they crank > up dom.ipc.processCount > 1. This is true even when they're doing lots > of work in the background, like building. > > Here's what I suspect: > > 1) I suspect that given the same group of CPU heavy tabs, single-process > Firefox will currently perform better than e10s with a single content > process. I suspect we can reach parity here. > > 2) I suspect that OS X is where most of the pain is, and I suspect bug > 1161166 is a big part of it. > > Here's what I suggest: > > 1) Wait for Telemetry data to come in to get a better sense of who is > being affected and what conditions they are under. Hopefully, the > population who have dom.ipc.processCount > 1 are small enough that we > have useful data for the dom.ipc.processCount = 1 case. > > 2) Send me profiles for when you see it. > > 3) Be patient as we figure out what is slow and iron it out. Realize > that we're just starting to look at performance, as we've been focusing > on stability and making browser features work up until now. > > 4) Trust that we're not going to ship The Spinner Experience, because > shipping it as-is is beyond ill-advised. :D > > -Mike > > On 05/05/2015 10:49 AM, Ehsan Akhgari wrote: > > On 2015-05-05 10:30 AM, Mike Conley wrote: > >> The e10s team is currently only focused on getting things to work with a > >> single content process at this time. We eventually want to work with > >> multiple content processes (as others have pointed out, the exact number > >> to work with is not clear), but we're focused on working with a single > >> process because we believe this is a strictly easier backdrop to develop > >> against. > >> > >> Once we've got single content process nailed down, we can then start > >> exploring multiple content processes. > > > > I like roc and some other colleagues have also set the process count > > pref to 10 for a while and have not noticed any issues that were not > > present with one content process. However, I realize that a few > > people's anecdotes cannot be a good enough reason to change what we're > > planning to do here. :-) > > > > Is there a more detailed description of what the issues with multiple > > content processes are that e10s itself doesn't suffer from? > > > >> We might revisit that decision as things stabilize, but in the meantime > >> I want to stress something: if you're cranking up dom.ipc.processCount > >> to avoid the spinner, I suspect you are probably wallpapering over the > >> issue, and robbing us of data. We've just landed Telemetry probes to get > >> tab switch and spinner times[1]. If you bump up dom.ipc.processCount to > >> avoid the spinner, we miss out on knowing when you _would_ have seen the > >> spinner. This makes it harder for us to know whether or not things are > >> improving or getting worse. It makes it harder for us to identify > >> patterns about what conditions cause the spinner to appear. > > > > One of the extremely common cases where I used to get the spinner was > > when my system was under load (outside of Firefox.) I doubt that we're > > going to be able to fix anything in our code to prevent showing the > > spinner in such circumstances. Another such common case would be one > > CPU hungry tab. > > > > Are we planning on strategies to mitigate that general issue? It's not > > clear to me that replacing the (possibly invisible, or at least only > > visible in the UI animations) jank that we have without e10s when > > switching tabs with a very visible spinner icon in the middle of the > > content area is the right trade-off. Even though I _know_ the reason > > why we show the spinner, with my user hat on, I think when switching > > tabs, Firefox with 1 content process seems more sluggish than no-e10s, > > or rather, the visual effect that you'll get in case we show the spinner > > with e10s gives me a more sluggish experience than a few small > > animations in the UI stuttering. > > > > Cheers, > > Ehsan > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
