[Sugar-devel] Killing activities when memory gets short

[Tomeu Vizoso]

On Sun, Aug 8, 2010 at 18:11, Martin Langhoff <martin.langhoff at gmail.com> wrote:
> Hi Tomeu,
>
> in general, I think we are saying the same thing :-)

My impression as well.

> With one exception -- OOM happens because memory is allocated.
> Sugar-shell cannot (and I say should not) try to arbitrage in there.
> If we try to do it from sugar-shell, all we can do is poll. If we poll
> infrequently, we won't catch them, if we poll frequently, we'll burn
> battery, introduce random lags... and still not catch many.

Well, we certainly should not poll, I started this thread because
recent kernels have a mechanism for getting notified when a certain
threshold of free memory is reached (see below).

> When the shell is in the bg, IMHO it should be as "dormant" as possible.

Sounds a worthy goal.

> There are some opportunities for the shell to step-in in a friendly
> manner -- activity open, activity switch, I propose that those events
> are a natural place; and if a delay happens there is not very
> disruptive for users. Between those events checking for low-mem and
> seeding the OOM killer to catch runaways, we'll have something.

Yeah, oomadj would be updated on activity open and switch if we go that way.

> I don't know of there's a way to ask the OOM killer to run a process
> on a lower threshold -- or send a signal to an existing one, that'd
> make more sense :-) . If it does, we could have a tight C process
> listening there of OOM "warnings" and sending friendly "close now plz"
> dbus signals.

The kernel docs linked here mention such a mechanism:

http://lists.sugarlabs.org/archive/sugar-devel/2010-August/025851.html

Regards,

Tomeu

> cheers,
>
>
> m
> --
>  martin.langhoff at gmail.com
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>