From: Jonas Sicking <[email protected]> Subject: Re: [b2g] Overhauling the process priority manager Date: Mon, 1 Sep 2014 20:52:19 -0700
> On Mon, Sep 1, 2014 at 4:39 AM, Thinker K.F. Li <[email protected]> wrote: >> Jonas Sicking <[email protected]> writes: >> >>> On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto <[email protected]> >> >> wrote: >>>> >>>> Comments are *very* welcome. >>> >>> >> ...... skip ...... >> >>> >>> Third, when I have pondered this stuff in the past, it seemed to me >>> like a lot of the complexity comes from the fact that the system app >>> generally had most of the information about which app is most >>> important. However gecko made all the decisions. And the only way that >>> the system app could influence gecko was through setting various >>> properties through the browser API which only affected LMK levels CPU >>> priorities in indirect and complex ways. >> >> I am afraid it would be inefficient for the longer response time. For >> example, we would prefer to give the dialer a highest priority for ringing. >> So, we would try to lower the priority of the music player process at first >> monent if there is. The path of ring from RIL to system app is far too >> long/slow for some stressed circumstances. One solution is to break layers >> and pass events; like ring, to the system app through a shortcut, then we >> will expose a lot implementation details to the system app. > > Where is the extra overhead coming from? > > Is it because we have to go through the main thread in the parent process? > > Or is it because the system app is doing a lot of JS processing before > it actually creates an <iframe mozbrowser> element? > > Or is it because we run a lot of gecko code between the <iframe > mozbrowser> element has been created and we actually start talking to > the pre-forked app process? > > Or is it something else? Passing a ring message from ril worker to system app could take several hundred ms. There several circumstances contribute to the latency. One of the source of the latency comes from memory pressure. We could expect a lot of code and data are removed out of the cache of the kernel on the path of handling ring events. It costs a lot of time to load the code back from the flash (native) and swap (for JS code and data), and it would compete with other running processes for the cache; music player for example. > > / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
