Re: [Sugar-devel] Killing activities when memory gets short
2010/8/11 NoiseEHC noise...@freemail.hu: We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Since I spent quite a bit of time analyzing the Python runtime here is my conclusion, maybe it will make wasting all that time less painful. First, most of the memory consumed by an activity is the process heap. While the Python runtime and native libraries are shared among processes, the heap is not. Even if you fork processes it will not work because reference counting will dirty the shared pages This would hold true if a significant part of the stuff loaded during startup was actually ever referenced. This is not the case in Sugar, so you indeed can get quite some savings from the prefork trick. But of course, the right fix here is not sharing that memory, but not require it in the first place if we don't need it. One example is to stop compiling regular expressions eagerly, as mentioned in http://www.mail-archive.com/su...@lists.laptop.org/msg06957.html . There are several other situations that once fixed would give us wins in the order of hundreds of milliseconds with the corresponding wins in memory usage, such as importing modules that are never used. The move from PyGtk to introspection will mean we stop loading several dozens of classes that we never end up using, but there's lots to win in the Python std library as well. Regards, Tomeu and my instinct tells me that just loading a Python source file will reference almost all the shared pages because they are mostly used to store already loaded modules. What I finally did not do is to actually check the hypothesis that most of the heap is filled by strings which are the identifiers in the loaded Python modules. My goal was to somehow make identifiers constants and just readonly-mmap them into the process (replace the pathetic .pyc loading mechanism). Note that my plan was just a little subset of the .jar - .dex converter. Second, Python has a special memory manager which works with buckets so there are separate heaps for different object sizes. Somehow this special memory manager is turned off in release mode and it uses the standard C heap for some reason. Either it is a bug or just it turned out to be faster (more work was put into glibc) I do not know, but handling the linked free list can dirty shared pages as well or I am just mistaken... Third, the fact that Python is a dynamic language does not help any prefetching or memory sharing. I am not too convicted either that this dynamic nature is used at all in the Sugar codebase but you know I cannot program in Python and frankly I do not feel the need to learn another language. Just now, at my age of 34, I finally gave up and learned LISP (more specifically clojure) and I hope that it will be the last programming language I will have to learn (other than assembly languages of course)... :) Now this point is interesting because if you thought that the Dalvik VM could run the Sugar codebase via Jython then it just will not work. The Dalvik VM just cannot load .jar files and Jython just generates them on the fly because of the dynamic nature of Python. Fourth, moving Python (theoretically) to a GC environment (instead of reference counting) also would not work if the GC is compacting because it would also dirty the shared pages. So a mark and sweep nonmoving GC with separately stored visited bits is the only feasible solution. Now guess what the Dalvik VM does? For more info (45 min + questions): http://www.youtube.com/watch?v=ptjedOZEXPM So *my* conclusion is that solving this sharing problem is *very* hard. I am not sure that simply translating all activities from Python to Java would take more time. Another interesting thing is that meantime the unladen-swallow project progresses (just more slowly than planned). Their plan is to make it the default Python runtime so if it will happen (I cannot comment on that) then the Python VM will use even more memory (though it will be faster) so Sugar will be even less interesting on the myriad of low spec cheap ARM tablets which will flood the market soon. I think that is all I can say about this subject so I just finish it here. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
Hi James, On 11 Aug 2010, at 04:05, James Cameron wrote: On Tue, Aug 10, 2010 at 05:48:00PM -0700, John Gilmore wrote: ... and was also unsuccessful in convincing OLPC to prelink the shared libraries before shipping a release, thus allowing read-only pages to not get dirtied with shared library linkage relocations. 10.1.2 release candidate os851 has prelink before shipping, it's done in the builder. Out of curiosity, just been testing two XO-1s side by side one os850 and one os851. Rough observations (repeated about 12 times): - resuming/starting a sequence of activities after another reliably gets to 9 simultaneous activities (Terminal, Calculate, Log, Pippy, Implode, Chat, Moon, Paint, Memorize) - the tenth activity I happened to be testing, Turtle Blocks, usually triggered an OOM hang of some kind - the OOM hang was usually Turtle Blocks failing to launch. Failed launch would consist of the pulsing startup window, then hanging at a mainly dark grey screen with some partial toolbar light grey fill, non-responsive UI for ~30 seconds to a number of minutes (possibly 5 or 10min), finally you'd be dropped back at the last activity you had successfully launched (Memorize in my test cases). - on three occasions os851 successfully started Turtle Blocks - on one occasion os850 successfully started Turtle Blocks, however on one occasion resuming Turtle Blocks os850 managed to trigger an OOM kill of the Sugar shell resulting in all resumed activities dying and being dropped back at the home fav ring view. - as Turtle Blocks seems a little more memory intensive than some other activities, I tried a few others as the tenth and onward test case. Write as no. ten usually was fine and Distance as eleven. Then trying Maze, or Speak as no. twelve would trigger OOM and the activity would be killed (after some delay, as noted above). - on one occasion trying to start Maze in os850 as activity no. twelve, managed to trigger an OOM kill of the Sugar shell. So, not significant results over just 12 cycles for each XO-1 (need finer grained testing rather than 'number of activities'). Both exhibited long UI lockup's when launching an activity while resources were already maxed out, usually resulting with the activity in question being killed; but os850 did trigger OOM to kill the Sugar shell twice, bringing down all activities with it, where as os851 didn't. --Gary P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
gary wrote: P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) that's exactly right. :-) pre-linking has been in the builds for some time, i believe. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 11 Aug 2010, at 18:42, Paul Fox p...@laptop.org wrote: gary wrote: P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) that's exactly right. :-) pre-linking has been in the builds for some time, i believe. Lol! :-) At least it's nice to know that the usual OOM behaviour is that the just launched activity is the one that gets it in the neck, most of the time. Pity about the lockup that usually happens before the kill, is it possible to make the OOM happen at a higher free mem threshold? --Gary paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Since I spent quite a bit of time analyzing the Python runtime here is my conclusion, maybe it will make wasting all that time less painful. First, most of the memory consumed by an activity is the process heap. While the Python runtime and native libraries are shared among processes, the heap is not. Even if you fork processes it will not work because reference counting will dirty the shared pages and my instinct tells me that just loading a Python source file will reference almost all the shared pages because they are mostly used to store already loaded modules. What I finally did not do is to actually check the hypothesis that most of the heap is filled by strings which are the identifiers in the loaded Python modules. My goal was to somehow make identifiers constants and just readonly-mmap them into the process (replace the pathetic .pyc loading mechanism). Note that my plan was just a little subset of the .jar - .dex converter. Second, Python has a special memory manager which works with buckets so there are separate heaps for different object sizes. Somehow this special memory manager is turned off in release mode and it uses the standard C heap for some reason. Either it is a bug or just it turned out to be faster (more work was put into glibc) I do not know, but handling the linked free list can dirty shared pages as well or I am just mistaken... Third, the fact that Python is a dynamic language does not help any prefetching or memory sharing. I am not too convicted either that this dynamic nature is used at all in the Sugar codebase but you know I cannot program in Python and frankly I do not feel the need to learn another language. Just now, at my age of 34, I finally gave up and learned LISP (more specifically clojure) and I hope that it will be the last programming language I will have to learn (other than assembly languages of course)... :) Now this point is interesting because if you thought that the Dalvik VM could run the Sugar codebase via Jython then it just will not work. The Dalvik VM just cannot load .jar files and Jython just generates them on the fly because of the dynamic nature of Python. Fourth, moving Python (theoretically) to a GC environment (instead of reference counting) also would not work if the GC is compacting because it would also dirty the shared pages. So a mark and sweep nonmoving GC with separately stored visited bits is the only feasible solution. Now guess what the Dalvik VM does? For more info (45 min + questions): http://www.youtube.com/watch?v=ptjedOZEXPM So *my* conclusion is that solving this sharing problem is *very* hard. I am not sure that simply translating all activities from Python to Java would take more time. Another interesting thing is that meantime the unladen-swallow project progresses (just more slowly than planned). Their plan is to make it the default Python runtime so if it will happen (I cannot comment on that) then the Python VM will use even more memory (though it will be faster) so Sugar will be even less interesting on the myriad of low spec cheap ARM tablets which will flood the market soon. I think that is all I can say about this subject so I just finish it here. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Tue, Aug 10, 2010 at 05:48:00PM -0700, John Gilmore wrote: ... and was also unsuccessful in convincing OLPC to prelink the shared libraries before shipping a release, thus allowing read-only pages to not get dirtied with shared library linkage relocations. 10.1.2 release candidate os851 has prelink before shipping, it's done in the builder. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 11 Aug 2010, at 01:56, Lucian Branescu lucian.brane...@gmail.com wrote: 2010/8/10 NoiseEHC noise...@freemail.hu: We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Since I spent quite a bit of time analyzing the Python runtime here is my conclusion, maybe it will make wasting all that time less painful. First, most of the memory consumed by an activity is the process heap. While the Python runtime and native libraries are shared among processes, the heap is not. Even if you fork processes it will not work because reference counting will dirty the shared pages and my instinct tells me that just loading a Python source file will reference almost all the shared pages because they are mostly used to store already loaded modules. What I finally did not do is to actually check the hypothesis that most of the heap is filled by strings which are the identifiers in the loaded Python modules. My goal was to somehow make identifiers constants and just readonly-mmap them into the process (replace the pathetic .pyc loading mechanism). Note that my plan was just a little subset of the .jar - .dex converter. Second, Python has a special memory manager which works with buckets so there are separate heaps for different object sizes. Somehow this special memory manager is turned off in release mode and it uses the standard C heap for some reason. Either it is a bug or just it turned out to be faster (more work was put into glibc) I do not know, but handling the linked free list can dirty shared pages as well or I am just mistaken... Third, the fact that Python is a dynamic language does not help any prefetching or memory sharing. I am not too convicted either that this dynamic nature is used at all in the Sugar codebase but you know I cannot program in Python and frankly I do not feel the need to learn another language. Just now, at my age of 34, I finally gave up and learned LISP (more specifically clojure) and I hope that it will be the last programming language I will have to learn (other than assembly languages of course)... :) Now this point is interesting because if you thought that the Dalvik VM could run the Sugar codebase via Jython then it just will not work. The Dalvik VM just cannot load .jar files and Jython just generates them on the fly because of the dynamic nature of Python. Fourth, moving Python (theoretically) to a GC environment (instead of reference counting) also would not work if the GC is compacting because it would also dirty the shared pages. So a mark and sweep nonmoving GC with separately stored visited bits is the only feasible solution. Now guess what the Dalvik VM does? For more info (45 min + questions): http://www.youtube.com/watch?v=ptjedOZEXPM So *my* conclusion is that solving this sharing problem is *very* hard. I am not sure that simply translating all activities from Python to Java would take more time. Another interesting thing is that meantime the unladen-swallow project progresses (just more slowly than planned). Their plan is to make it the default Python runtime so if it will happen (I cannot comment on that) then the Python VM will use even more memory (though it will be faster) so Sugar will be even less interesting on the myriad of low spec cheap ARM tablets which will flood the market soon. I think that is all I can say about this subject so I just finish it here. The PyPy project has a fully-featured python 2.5 interpreter that has much lower memory usage and a proper GC (so less dirty pages). They also have an x86 JIT which makes it much faster than CPython, at the cost of a bit of memory (still less than CPython). The only issue right now is extension support: ctypes is fully supported, but C/Python extension support is not complete by far. FWIW I experimented with PyPy a month or so back to see how fast my self organising map code would run. Needed to make a some code/module changes to get it to work, but it ran about twice as fast. I didn't check if memory usage had improved. --Gary As for Jython on Android, Jython has a Java bytecode JIT. It should be entirely possible to write a dalvik backend to this JIT. So not only would rewriting everything to Java be a huge step backwards, but it would also be more work. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] Killing activities when memory gets short
On 09.08.2010, at 01:21, John Gilmore wrote: As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. - Bert - (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 9 August 2010 11:25, Bert Freudenberg b...@freudenbergs.de wrote: On 09.08.2010, at 01:21, John Gilmore wrote: As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. - Bert - (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. On Android, all (good) apps always save their state. There may be some bad ones, but all the ones I've used do it properly. Since apps are made out of activities (views) connected by intents, all the activities in an app save state. When starting an app, the main activity decides what to show (saved or new state) or it can switch to another activity that was active when the app was killed. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote: Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Mon, Aug 9, 2010 at 15:47, Lucian Branescu lucian.brane...@gmail.com wrote: On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote: Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Regards, Tomeu (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 01:37, Marco Pesenti Gritti ma...@marcopg.org wrote: On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com wrote: 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. As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... +1, that would be an ideal solution. Minimal interface distinction between active and dormant activities; fast resume (perhaps some visual trickery using the thumbnail image to help cover any delay); improve activity UI state saving. --G Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: 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). Can't we just _close it nicely_? I have extremely rarely seen a Sugar app not closing. Sugar shell can decide it's a good idea to close an activity because too many are open and system is under memory pressure. Sugar apps auto-save, so closing nicely should work very nicely... 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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: 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). Can't we just _close it nicely_? When you are about to get into OOM? Don't think so because it's very probable that the kernel will block or kill something randomly before the activity or the user react. But as I said, before we reach this point we should have given the activities and/or the user the option to avoid this situation. Regards, Tomeu I have extremely rarely seen a Sugar app not closing. Sugar shell can decide it's a good idea to close an activity because too many are open and system is under memory pressure. Sugar apps auto-save, so closing nicely should work very nicely... 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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Can't we just _close it nicely_? When you are about to get into OOM? Early on so we avoid OOM for most cases. Right now our OOM use cases have nothing to do with misbehaved activities. Once you're in about to get into OOM, sugar-shell is unlikely to get many cycles (and python is a bad lang to try handling this). If you can seed the OOM scores of the process early on, you have a chance that OOM will kill a reasonably correct one. (Not sure what the state of play is with seeding the OOM scores from userland). point we should have given the activities and/or the user the option to avoid this situation. I think it's the only thing we can reasonably do. And [if possible], seed OOM scores. When things get tight, only the kernel has a standing chance to run code. 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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 11:42 AM, Martin Langhoff martin.langh...@gmail.com wrote: (Not sure what the state of play is with seeding the OOM scores from userland). http://linux-mm.org/OOM_Killer The pid of the activity should have its oomadj bumped up a bit -- so OOM knows to spare sugar-shell and friends... 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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 17:42, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Can't we just _close it nicely_? When you are about to get into OOM? Early on so we avoid OOM for most cases. Right now our OOM use cases have nothing to do with misbehaved activities. Once you're in about to get into OOM, sugar-shell is unlikely to get many cycles (and python is a bad lang to try handling this). If you can seed the OOM scores of the process early on, you have a chance that OOM will kill a reasonably correct one. (Not sure what the state of play is with seeding the OOM scores from userland). I tried to make clear before that by all means I think we should give the user and activities the chance to do what is best early on. point we should have given the activities and/or the user the option to avoid this situation. I think it's the only thing we can reasonably do. And [if possible], seed OOM scores. When things get tight, only the kernel has a standing chance to run code. Well, the shell would kill activities before we get that tight. But I agree that if if we can use OOM scores to have the kernel kill the less bad thing, that sounds better. 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
Re: [Sugar-devel] Killing activities when memory gets short
Hi Tomeu, in general, I think we are saying the same thing :-) 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. When the shell is in the bg, IMHO it should be as dormant as possible. 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. 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. 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
Re: [Sugar-devel] Killing activities when memory gets short
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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 12:36 PM, Tomeu Vizoso to...@sugarlabs.org wrote: 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). ... http://lists.sugarlabs.org/archive/sugar-devel/2010-August/025851.html u. apologies for wasting bandwidth. Over the course of the thread I missed that bit. Excellent info. thanks for your patience! 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
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 2:33 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: 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). Can't we just _close it nicely_? When you are about to get into OOM? Don't think so because it's very probable that the kernel will block or kill something randomly before the activity or the user react. But as I said, before we reach this point we should have given the activities and/or the user the option to avoid this situation. Not sure what the requirements would be of implementing something like iphone/ipod (well versions prior to 4) where when the Activity is backgrounded it saves its state and quits so you don't really have more than one app running at a time? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
Sent from my iPad On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: 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: I read through the thread but may also missed something. - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). True. - 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). The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Best regards, Tiago 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 ___ 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
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. An opt out could be easily abused... In the PDF case the activity could be closed and reopened under the hoods, without the user even noticing (well, startup time aside). Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 August 2010 20:33, Marco Pesenti Gritti ma...@marcopg.org wrote: On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. An opt out could be easily abused... In the PDF case the activity could be closed and reopened under the hoods, without the user even noticing (well, startup time aside). Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Activities already write_file when they lose focus, they could write_file periodically or at least when warned of low memory. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 20:38, Lucian Branescu lucian.brane...@gmail.com wrote: Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Activities already write_file when they lose focus, they could write_file periodically or at least when warned of low memory. Yes, that's how I think it should work. Of course activities will need to do a better work to save all the possible state, because we are closing without user intervention. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 August 2010 20:51, Marco Pesenti Gritti ma...@marcopg.org wrote: On 8 Aug 2010, at 20:38, Lucian Branescu lucian.brane...@gmail.com wrote: Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Activities already write_file when they lose focus, they could write_file periodically or at least when warned of low memory. Yes, that's how I think it should work. Of course activities will need to do a better work to save all the possible state, because we are closing without user intervention. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) An activity frontend to MPD could be killed following activity policy and the MPD daemon itself would be killed following regular daemon policy. Music would play after the activity dies and would only be stopped if the MPD daemon is killed (which is less likely since it uses very little memory). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 20:57, Lucian Branescu lucian.brane...@gmail.com wrote: Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) An activity frontend to MPD could be killed following activity policy and the MPD daemon itself would be killed following regular daemon policy. Music would play after the activity dies and would only be stopped if the MPD daemon is killed (which is less likely since it uses very little memory). Ah yeah that could work for global services. It would be good if the same could be done at activity level though. You could use the a similar mechanism but it would require figuring out how to launch these services, register them with the shell etc. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Killing activities when memory gets short
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. 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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sat, Aug 7, 2010 at 19:31, 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. 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. 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 - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sat, Aug 7, 2010 at 19:33, Tomeu Vizoso to...@sugarlabs.org wrote: On Sat, Aug 7, 2010 at 19:31, 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. 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 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 - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
El Sat, 07-08-2010 a las 19:33 +0200, Tomeu Vizoso escribió: 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. That would be a good question for Dan (cc'd :-). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sat, Aug 7, 2010 at 1: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 I think we can just win big time without polling and without killing. - grab the python code from ps_mem.py. We' ll be reading mem usage from our own processes (w/o rainbow at least) so I suspect no need for priv operation - when the user opens a new activity, poll used/free memory with some pre-set constants and if warranted send a 'close' signal to the best candidate (weighed LRU + mem usage score) -- depends on closing without asking for a document name... - Opportunistic checks on activity switch, view change can complement this. The above matches what my Android phone does and as a user, works great. 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
Re: [Sugar-devel] Killing activities when memory gets short
On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com wrote: 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. As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
