Gabriele, thanks for the note. I presume this will impact behavior of apps around app-switching, e.g. any app that do any significant clean-up when receiving visibilitychange will be slow down. Is that correct?
I would also afraid such bug show up on v2.2 down the road which will be very hard to address. So I wonder if it's possible to disable this change in v2.2 branch. Other than that this sounds like a positive change :) On Fri, Jan 9, 2015 at 5:52 AM, Fabrice Desré <[email protected]> wrote: > Thanks for working on this Gabriele, that was long overdue, and thanks > to Dave for the reviews! > > I have one question: afaik we still use ICS for emulator tests. I guess > try runs went fine but I wonder if that impacted test flakiness in any way. > > Fabrice > > On 01/08/2015 01:13 PM, Gabriele Svelto wrote: >> [cross-posting to dev-gaia because this will affect everybody] >> >> TL;DR I am about to land cgroup support; this changes the low-level >> mechanism we use to prioritize applications. If you see unsual >> slow-downs during application startup or when more than one app is >> active at the same time, leave a comment on bug 1081871 [1]. We'll back >> it out mercilessly if perceived performance regresses. >> >> --- >> >> Now for the long story. I'm delving in a bit of project history here >> because this topic is rather obscure to most and I'd like more people to >> be aware of it and of the reasoning behind our past and current choices. >> >> In the early days of the B2G project we were looking for a mechanism to >> prioritize applications' CPU usage. Our very first implementation relied >> on changing a process' nice value (bug 768832 [2]) but turned out to be >> broken as changing a process' nice value on Linux only affects the main >> thread. >> >> So we decided to try another mechanism that provided a reliable way to >> re-prioritize an entire process: control groups, cgroups in short [3]. >> Control groups use a pseudo file-system that allows creating classes of >> applications with certain properties assigned to them, such as how much >> CPU should be allocated to the group. cgroups allow splitting CPU >> priority by group rather than by app which is very convenient(e.g. all >> background applications together should get no more than 5% of the total >> CPU time in the presence of a foreground app requiring as much CPU as >> possible). >> >> While they would have made a perfect fit for our requirements, ICS' >> cgroup implementation proved to be buggy as we found out in bug 861441 >> [4]. While we might have worked around its bugs we feared the resulting >> system would be fragile. Instead we decided to keep using the tested and >> true nice values even though using them to re-prioritize an entire >> process required a lot of syscalls (which was expensive) and would >> expose us to rare race conditions. >> >> The resulting implementation worked for most cases but fell apart under >> extreme scenarios such as receiving a call with both high CPU usage and >> strong memory pressure (bug 870181 [5]). This was also fixed but only at >> the cost of a lot of added complexity in the process priority manager. >> >> Enter post-ICS kernels. cgroups now work properly, are obviously a >> better fit than nice values for CPU priority assignment, and also offer >> additional features such as altering an application swappiness which is >> handy on devices using zram. In this new scenario we decided it's time >> to switch to using cgroups for all our prioritization needs; this is >> happening in bug 1081871 [1]. >> >> What does this mean to you? First of all switching an app priority >> should become a lot faster and should work reliably no matter how much >> load the phone is subject to. Second, the rigid segregation of processes >> within groups means it will be a lot harder for background apps to >> significantly slow down the phone; foreground apps should stay >> responsive at all times. Third, being able to balance CPU usage using >> relative proportions means we can now have a more fair allocation >> between the main process and content processes. Last but not least this >> will simplify the affected code a lot and shedding useless complexity is >> one of my favorite activities. >> >> One final note: if you're on an ICS device and you're on the master >> branch once bug 1081871 lands you might experience significant >> performance regressions. I will try to implement a workaround in bug >> 1119467 [6] so CC yourself there if you're affected. Geeksphone's >> devices (peak, keon) will also require some kernel modifications so I'll >> need to get them involved too. >> >> [1] Evaluate using cgroups instead of nice values for prioritizing processes >> https://bugzilla.mozilla.org/show_bug.cgi?id=1081871 >> [2] Set oom_adj values for background/foreground content processes >> https://bugzilla.mozilla.org/show_bug.cgi?id=768832 >> [3] https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt >> [4] GonkHal::SetPriority does not set CPU priorities properly >> https://bugzilla.mozilla.org/show_bug.cgi?id=861441 >> [5] Downgrade processes' CPU priorities when we receive a call >> https://bugzilla.mozilla.org/show_bug.cgi?id=870181 >> [6] Implement a workaround to have working cgroup assignments on >> ICS-based devices >> https://bugzilla.mozilla.org/show_bug.cgi?id=1119467 >> >> >> >> _______________________________________________ >> dev-gaia mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-gaia >> > > > -- > Fabrice Desré > b2g team > Mozilla Corporation > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
