But it already does, right? There are two examples shown below where we treat <512mb as a special case. There is already piece of Gecko code that treats <=256mb as a special case. I don’t like it either, but I’d at least like all the things we don’t like to be consistent. What you guys are talking about below is awesome, but it either comes down to setting a preference specific to each device, or some run time heuristic we don’t already have. In the meantime, people running with 273mb Flames are treated by Gecko as “high memory” devices, since the system memory is > 256mb. -- - Milan
On Jul 31, 2014, at 14:17 , James Ho <[email protected]> wrote: > I don't like a simple 256/512 number to be only factor that differentiates > normal/low-mem devices. Can somebody come out a more realistic equation for > that? A few factors I can call out are, screen resolution, BSP/driver > overhead such as modem/drivers, etc. Also, we need a tool to measure the > memory usage, we can probably take the number we get from MTBF test as the > maximum reasonable memory we need for b2g itself alone. > > -- > James Ho > Senior Director of Mobile Devices > Mozilla Corporation > > On Jul 31, 2014, at 10:18 AM, Milan Sreckovic <[email protected]> wrote: > >> >> So. Is this “official"? There is at least one place in Gecko that we can >> change from “low memory is <= 256” to “low memory is < 512”, but I don’t >> really want to do it unless we’re all agreeing to this. Any code in Gaia >> that is currently doing special things with other numbers will stop, and >> we’ll just look at < 512mb from now on? >> >> Is it worth having this as a constant/preference? >> >> -- >> - Milan >> >> On Jul 28, 2014, at 23:20 , Tim Chien <[email protected]> wrote: >> >>> Input management copy the same number (from the same patch) and >>> running keyboard inproc when memory is < 512mb. >>> >>> https://github.com/mozilla-b2g/gaia/blob/be5fc7f8d2bb6f6ad61294a6e2219827b9930901/apps/system/js/keyboard_manager.js#L421-L429 >>> >>> On Tue, Jul 29, 2014 at 6:34 AM, Kevin Grandon <[email protected]> wrote: >>>> Sounds good to me. This is actually exactly what we do for the home >>>> screen. We have two different profiles, one with 'high' capabilities, and >>>> one with 'low'. Low capability devices are defined with anything less than >>>> 512mb of memory. >>>> >>>> https://github.com/mozilla-b2g/gaia/blob/e13f1f667a49160c3fa3eab89e189910c46b04dc/apps/verticalhome/js/configurator.js#L172 >>>> >>>> Best, >>>> Kevin >>>> >>>> ----- Original Message ----- >>>> From: "Lucas Adamski" <[email protected]> >>>> To: "dev-b2g" <[email protected]>, "dev-gaia" >>>> <[email protected]> >>>> Sent: Monday, July 28, 2014 3:26:58 PM >>>> Subject: Low-memory code paths >>>> >>>> Hi all, >>>> >>>> In trying to address performance in memory constrained devices, a number >>>> of features have been implemented to conserve memory. The problem is >>>> these are kicking in at various memory thresholds (256MB, 300MB, etc). >>>> >>>> This means we see inconsistent behavior when testing Flame in configs like >>>> 273MB and 319MB, where memory usage actually regresses with the addition >>>> memory being provided. >>>> >>>> Given the only RAM amounts we’re planning on shipping are in a geometric >>>> sequence, we should instead treat any memory amount < 512MB as a memory >>>> constrained devices (a further threshold may make sense < 256MB for >>>> Tarako). >>>> >>>> Thoughts, concerns, discussion? >>>> Lucas. >>>> _______________________________________________ >>>> dev-gaia mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-gaia >>>> _______________________________________________ >>>> dev-gaia mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-gaia >>> >>> >>> >>> -- >>> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox >>> OS, Mozilla Corp. (Taiwan) >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g >> >> _______________________________________________ >> 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
