[Sugar-devel] Killing activities when memory gets short
Tomeu Vizoso
tomeu at sugarlabs.org
Sun Aug 8 12:36:36 EDT 2010
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
>
More information about the Sugar-devel
mailing list