Killing activities when memory gets short

Tiago Marques tiagomnm at
Sat Aug 7 16:08:30 EDT 2010

Hi all,

On Sat, Aug 7, 2010 at 6:31 PM, Bernie Innocenti <bernie at> wrote:

> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió:
> > So we would have a periodic wakeup? The test would be the amount of
> > free memory plus buffers and caches?
> A polled design is clearly inferior to a proper notification system, but
> it has the advantage of being simple and not requiring a particular
> kernel. Once this is done, switching to a better solution should not
> require extensive changes to the UI code.
> BTW, looking at top, it seems that Sugar and other processes wake up
> quite frequently when the system is supposed to be completely idle. It
> may be background checks for updates, NetworkManager updates or the
> presence service. Plus, there are a bunch of cron jobs that run in the
> background, inclding the ds-backup and olpc-update.
> All these things drain battery power and cause the UI to become jerky,
> so we should try to limit them if possible.
> > > Or, maybe, we could make this a manual process: pop up a notification
> > > when memory is short and ask which activity should be closed.
> >
> > I would just close one of the background activities, the LRU or the
> biggest one.
> +1.

Just killing a random activity is a terrible idea becayse you don't want
your product behaving like it's defective; the pop up idea is way more
acceptable(and a lot better than having the system randomly behaving like
it's crashed). Either way, this is the extremely important use of swap
memory that doesn't exist here. I understand your engineering constraints on
the hardware but randomly killing activities is poised to confuse users and
cause people considering the hardware for deployment to think that you're
selling them something defective/baddly manufactured.

Best regards,
Tiago Marques

> This, however, makes non-sugarized activities more dangerous to deal
> with. One more reason to demand proper sugarization.
> --
>   // Bernie Innocenti -
>  \X/  Sugar Labs       -
> _______________________________________________
> Devel mailing list
> Devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list