On 14/11/2013 23:27, lhila...@mozilla.com wrote:
A pair of wild ideas from a barely initiated n00b. I apologize if I don't have
proper context or these ideas are naive. Whatever the case, I'm sure it will
be educational for me.
This particular piece of functionality is quite complicated so it's not
surprising that the way some parameters were set confused you :) We (and
by we I mean I) should really make a full write-up of how the whole
chain of low-memory notification works because it's quite complex.
Idea 1: as I crawl around on my ZTE open I see some suspicious configuration:
first, in /sys/module/lowmemorykiller/parameters/minfree
1024,1280,1536,1792,2048,5120
next, in /sys/module/lowmemorykiller/parameters/notify_trigger
3584
The question: Why are we notifying of memory pressure when we get down 14mb but
killing off application level (adj >= 10) processes, before that, at 20mb?
The reason why we do that is that whenever an application is sent into
the background we also send it a message that forces it to minimize its
memory usage, see here:
http://hg.mozilla.org/mozilla-central/file/7b014f0f3b03/dom/ipc/ProcessPriorityManager.cpp#l1024
So in general there's not much to be made by sending memory-pressure
events to background apps. They're usually already minimized which is
why we want the low-mem killer to get rid of them before we start to
send memory-pressure events.
You can find part of the discussion on why the trigger was put at that
particular level (together with some of the experiments that led to it)
in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=877222
The idea: Is lowmemorykilling for adj >= 10 down at 10mb undesirable for some
reason? would these be better parameters which allow us to delay killing
processes until we've had a chance to respond to the low memory event that raises
up via GonkMemoryPressureMonitoring.cpp?
We arrived at those parameters by testing different combinations.
They're not optimal but for now they're the best we could come up with.
One of the issues of setting the lowmemkiller parameters too low is that
they can cause instability as available memory dries up potentially
leaving enough memory only for one app, preventing everything else from
running.
Idea 2: I'm having a hard time tracing what lowmemorykiller notifications
trigger. Is this documented anywhere?
That's one of the thing I should really write somewhere :) What's
happening is that the memory pressure monitor fires some memory-pressure
events. Those are delivered to the interested objects (caches, GC,
etc...). Look for lines like this one:
http://hg.mozilla.org/mozilla-central/file/7b014f0f3b03/dom/ipc/ContentParent.cpp#l758
Those messages are also propagated from the main process to all
applications, see here:
http://hg.mozilla.org/mozilla-central/file/7b014f0f3b03/dom/ipc/ContentParent.cpp#l1967
It would seem with a notification up a little higher (perhaps at 20meg where
the killing happens today) we could deliver a message to non-foreground
applications that could choose to ignore it, or choose to shut themselves down
cleanly and dodge the reaper.
In general that doesn't work; when an application is starting to consume
memory it happens too fast for background applications to react in a
timely manner. Trying to minimize the memory of background applications
consumes CPU and that's also something we don't want in a number of
scenarios.
For example, when receiving an incoming call we need the dialer
application to start up fast. If there's not enough memory the best
option is to kill some other app; that saves the memory without
burdening the CPU thus allowing the user to see the incoming call ASAP.
So the idea is, should we consider application level events when we detect
impending memory pressure?
That's something I've considered but ATM there's no way to let the
content code detect those events and it's unclear if letting those
events known to the actual apps would be beneficial.
Gabriele
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
