Killing activities when memory gets short

Tomeu Vizoso tomeu at
Sat Aug 7 13:36:09 EDT 2010

On Sat, Aug 7, 2010 at 19:33, Tomeu Vizoso <tomeu at> wrote:
> On Sat, Aug 7, 2010 at 19:31, 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.
> NM is particularly active when there are more than a few APs
> available, wonder if it would be possible to tune it to group updates
> in batches.

On a second thought, Sugar should probably only listen to events
relevants to what is being currently displayed. This would display
outdated data for a short while and would mean significant rework but
may be a worthy goal for the future.



> Regards,
> Tomeu
>>> > 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.
>> This, however, makes non-sugarized activities more dangerous to deal
>> with. One more reason to demand proper sugarization.
>> --
>>   // Bernie Innocenti -
>>  \X/  Sugar Labs       -

More information about the Devel mailing list