My concern is not that we’ll now have two, but that we already have 4 or 5 that are pretty random. So we’re better off having two (<256 and <512) than an undefined number (<=128, <256, <=256, <273, <300, <319, <512 etc) that often regress functionality in unpredictable ways. Lucas.
So I think the right question is are you trying to solve a Tarako (128MB) problem or a 256MB problem, and pick the corresponding branch (<256, <512). Lucas. On Jul 31, 2014, at 11:52 AM, Milan Sreckovic <[email protected]> wrote: > 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
