On Sat, Aug 7, 2010 at 22:08, Tiago Marques <tiago...@gmail.com> wrote: > Hi all, > > On Sat, Aug 7, 2010 at 6:31 PM, Bernie Innocenti <ber...@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 >> de...@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel