Killing activities when memory gets short

[Tomeu Vizoso]

On Sat, Aug 7, 2010 at 22:08, Tiago Marques <tiagomnm at gmail.com> wrote:
> Hi all,
>
> On Sat, Aug 7, 2010 at 6:31 PM, Bernie Innocenti <bernie at codewiz.org> 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.

I tihnk I have been sloppy with my words, so let me clarify two things:

- killing processes should be done only to avoid OOM (because
currently the kernel kills the wrong thing most of the time).

- before the need for killing arises, we can do a myriad of things to
prepare the user for what is coming and maybe to avoid it (some good
ideas have already been posted in this thread).

Regards,

Tomeu

> Best regards,
> Tiago Marques
>
>>
>> This, however, makes non-sugarized activities more dangerous to deal
>> with. One more reason to demand proper sugarization.
>>
>> --
>>   // Bernie Innocenti - http://codewiz.org/
>>  \X/  Sugar Labs       - http://sugarlabs.org/
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>
>