On Sun, Aug 8, 2010 at 18:11, Martin Langhoff <martin.langh...@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.langh...@gmail.com > mar...@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 > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel