Re: [Sugar-devel] OOM conditions
On Fri, Nov 06, 2009 at 04:50:53PM +, Tomeu Vizoso wrote: On Wed, Nov 4, 2009 at 14:16, Martin Dengler mar...@martindengler.com wrote: On Fri, Oct 30, 2009 at 11:22:13PM +0100, Tomeu Vizoso wrote: On Fri, Oct 30, 2009 at 16:58, Richard A. Smith rich...@laptop.org wrote: Working the table at the Boston book festival I was reminded how painful the OOM stuff is on a gen 1. The demo machines were in this state a lot as each visitor would open up a new program. Basically you have to just turn the unit off and restart as trying to recover is futile. What if activities had a higher oom_score? Would that protect enough the processes that once killed require a system restart (X, shell, etc)? See patch vs sugar-toolkit HEAD below[1] (I can backport to 0.82 if wanted). Maybe would be better to have the shell do that? So it works for non-python activities. Patch inline below. Regards, Tomeu Martin Thanks, Tomeu Martin (untested) patch against http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/activity/activityfactory.py : From 4bd6fb9f7f245c2aed92d6964746627d0c96cbec Mon Sep 17 00:00:00 2001 From: Martin Dengler mar...@martindengler.com Date: Sat, 7 Nov 2009 10:55:16 + Subject: [PATCH] sacrifice activities to the OOM killer first change the OOM-killer score of launched activities to be the maximum. See discussion at http://linux-mm.org/OOM_Killer --- src/sugar/activity/activityfactory.py | 35 + 1 files changed, 35 insertions(+), 0 deletions(-) diff --git a/src/sugar/activity/activityfactory.py b/src/sugar/activity/activityfactory.py index ee0fd92..5deee6e 100644 --- a/src/sugar/activity/activityfactory.py +++ b/src/sugar/activity/activityfactory.py @@ -65,6 +65,39 @@ def _close_fds(): pass +def __oom_adj_pid(pid, omm_adj_value=None): + Change a process' OOM likelihood to oom_adj_value. + +By default, use the value of gconf path +/desktop/sugar/performance/oom_adj_default; if none exists, make +this process most likely to be killed (oom_adj_value=15). + +Linux-specific. See http://linux-mm.org/OOM_Killer for details. + +oom_adj_fullpath = /proc/%s/oom_adj % pid +if os.path.exists(oom_adj_fullpath): +try: + +# get values/defaults from gconf +import gconf +gconf_dir = /desktop/sugar/performance +gconf_key = oom_adj_default +client = gconf.client_get_default() +if not client.dir_exists(gconf_dir): +client.add_dir(gconf_dir, gconf.CLIENT_PRELOAD_NONE) +if oom_adj_value is None: +oom_adj_value = client.get_int(gconf_dir + / + gconf_key) +if oom_adj_value is None: +oom_adj_value = 15 +client.set_int(gconf_dir + / + gconf_key, + oom_adj_value) + +file(oom_adj_fullpath).write(oom_adj_value) + +except: +pass + + def create_activity_id(): Generate a new, unique ID for this activity pservice = presenceservice.get_instance() @@ -276,6 +309,8 @@ class ActivityCreationHandler(gobject.GObject): stdout=log_file.fileno(), stderr=log_file.fileno()) +__oom_adj_pid(child.pid) + gobject.child_watch_add(child.pid, _child_watch_cb, (environment_dir, log_file)) -- 1.6.2.5 pgpEaiU3d05Vb.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Volunteer Opportunity
Mor than the hardware or whether its using a wlan/jabber or even mesh networking, there are serious underlying problems with collaboration itself, and my belief is they are in the sugar presence module, though I could be wrong. Under gnome, mission control 5 is responsible for doing presence stuff, connections with whathever connetion manager is wanted, and initial chat inititiation or much creation... from there other parts of telepathy get involved, though in general its just telepathy that does all the stuff, and from where the dtubes get involved with the sharing, the problems seem to stop. That is to say, once a connection has been established between one ore more other parties, the ride is smooth, the connection stays up and the collaboration is quite fast and reliable... Its what happens before this that causes many issues... The detecting of shared activities, users, intitiating connections, etc. My suggestion was to get rid of sugar presence and go the gnome/kde way and directly use telepathy's mission control 5, which in my experience works very well. I've done some initial testing, got some python scripts that do the creation, detecting of users, creation of local link mucs, etc... and it all seems to work smoothly, though I've done non of this in the sugar environment. If you do take this on, I'd be more than happy to help as telepathy itself fascinates me, and I've studied the dbus bindings themselves quite extensively. Empathy, which is built on telepathy seems to work quite flawlessly too, as do many of the chat clients and other apps used in maemo/neo freerunner/android Abiword, inkscape and several gnome game apps use telepathy without issues too (sudoku and tic tac toe come to mind) but I'm by no means a python or C guru, and have trouble with exactly how everything works... A lot of the code seems quite complex and I have difficulty following it, my own code for stuff being duplication of what already exists out there, and I'd love to be able to have more knowledge to be able to do more pure collaboration (All the code involved up to the dtube stage and then the use of the remote dbus bindings for programs, presumably, one would have to crate these remote dbus bindings too, another part of all this I'm unsure about) But yeah... for me sugar presence should be migrated to mission control 5 and I'd bet we'd see a lot of problems just dissapear... kind regards, David Van Assche On Sat, Nov 7, 2009 at 2:36 AM, Gary C Martin g...@garycmartin.com wrote: On 6 Nov 2009, at 22:03, Sascha Silbe wrote: On Fri, Nov 06, 2009 at 12:17:32PM -0800, Edward Cherlin wrote: My experience is that the problems with Collaboration are basic problems with mesh networking, presumably in hardware, drivers, and protocols. While I can't (and won't) rule out the local network links (i.e. WLAN in whatever mode), I'm usually connected to a Jabber server using wired networks; still Collaboration doesn't work reliably. +1 I occasionally run test sessions of 4-6 VM Sugar clients using Salut on an internal network (VM simulated, never touching wire/wireless) and even basic buddy presence often borks out after ~20min of use. The usual fail case is that one client stops seeing all others, but all others always pretend to see the missing client (even if it is really not there). The only resolution is to reboot all VM clients and hope they all can see each other for a while longer. The often mentioned 'it's poor wireless' may well be an issue in some cases, but it's certainly not the main one I see when testing collaboration, I dread to think what a class of 30 kids would see if collaboration was needed as a core part of a 40min lesson. Unfortunately I'm out of my depth on making much head way in pin pointing the issues (at one point I even started thinking it was dbus intermittently dropping messages). Regards, --Gary CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/___ 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 -- Ted Turner http://www.brainyquote.com/quotes/authors/t/ted_turner.html - Sports is like a war without the killing. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OT: waiting for non-child processes on Linux
On Fri, Nov 6, 2009 at 5:28 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: For the sugar-datastore test suite, I'd like to run each test at a clean state, i.e. from an empty directory and using a new data store service process (esp. important for migration tests which I'm currently working on). To ensure that, I need to a) find out the process id of the current data store service process (moderately easy, already implemented) b) kill it and c) wait for it to die. The last part is suprisingly hard as it's a distant cousin (started by dbus-daemon, so even different session and group id) and wait*() only work for immediate child processes. POSIX allows implementations to provide extensions that support waiting for arbitrary processes, I couldn't find any system call on Linux that does so (but might have overlooked one). Even starting a new process hierarchy (including dbus-daemon) from the top-level process for each single test case wouldn't help since dbus-daemon and its children (esp. the data store service process) cannot be waited for. :-/ Any idea on how to accomplish the given goal (without resorting to hacks like periodically starting pgrep)? Hello, There have been some people implementing a userspace kqueue library for Linux (partly to get Grand Central Dispatch running), who have the same problem. I don't think they have an answer yet, but you might bring it up on their mailing list http://mark.heily.com/libkqueue/ yours, Bobby CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJK9KMVAAoJELpz82VMF3Dae5kH/1Oow8ovGBNqbSquNyH0yiL2 y6VCpEXVol4M4au9v1JGObQh4r4I1cJ+H6nz3tL8rFtgeFPOhfBddCQAqtZSk2kk gmA2u0AjnkbrklM+bEA7s1BrP23EUlaXXL0SpxDZNj6lQu44qvJPc3IFf1UjqWu3 F/H2XXPd7c/UOlnrZvTzanGpciu7ze3Qrs1UkfmWauAwaaC9VkBYveNdxXAqb9P8 K4j9SQ4Q4wyxb4XKYXbteM9ei3skpyBiWCS5VJkLPB0qDeDZrHYYXIe1J114KA4p vX2twEJ/ZO9FqA5Eih0P3qs5efRl4HdjKE1FrCl1yle/BVSzez6iACK/mtFEuLc= =A8Jr -END PGP SIGNATURE- ___ 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] On Sugar 0.84 - status of the Chat/collab leader issue...
Hi, So I was looking over the code with some of the #telepathy guys who are also under the impression that sugar.presence code could be causing many of the collab problems. Main issue is redundancy of code... a lot of what is happening in sugar.presence already happens in telepathy (actually there are even comments in sugar.presence code stating this) but until we know to what level activities are using sugar.presence, we can't really do anything... since activities would break, I guess we'd need to know what in the sugar.presence modules is being really actively used to migrate to MC 5... and give a warning or something, or keep some kind of sym links to the old functions... I dunno, kinda above my level of expertise... regards, David van Assche On Fri, Nov 6, 2009 at 2:02 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Nov 4, 2009 at 13:16, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Martin Langhoff wrote: On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com wrote: moving to mission control 5 and letting go of the admittedly antiquated sugar presence now ... If you play with a major component replacement - test it for scalability stability over wifi before doing a lot of integration work It's worth noting that moving from the Sugar Presence Service to Mission Control 5 would not alter our network protocols. This is purely a change in how the client software is organized. Neither regression nor improvement in wireless network performance should occur. Was about to say this, the work means making sugar activities' code more similar to GNOME apps, while also removing a daemon. This could have some effect on how the network is used, but chances are it won't. As a first step in removing the PS, I think we should try to implement the python presence API with MC5 instead of PS. Then we can either drop the PS or make it a compatibility shim with MC5 while activities such as eToys make the move. We can also take the chance to develop a better API if there's need for it. But in any case, we need to do some exploration now before we can discuss it in detail. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Marie von Ebner-Eschenbachhttp://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html - Even a stopped clock is right twice a day. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] booth banner for Bolzano?
Hi Simon I will be bringing the Strawberry rollup booth banner to Bolzano; it will come in handy during Walter's talk and provide some visual scenery for us (as if the mountains weren't enough ;-) If you're able to bring the Blueberry banner, that would be great. If not, don't worry about it. I plan to bring several machines, any preferences from my collection which could be of use? XO-1s / Acer Aspire One / Acer Revo nettop / Dell Mini10v / Dell Latitude 2100 / EeePC / Classmate Gen1 Gen2 / Sony Vaio PCG-TR1 thanks Sean ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] questions about jquery.karma.js
On Sat, 2009-11-07 at 18:45 -0600, Felipe López Toledo wrote: That works for me. How about Sunday before 11 am EST? 11 am EST = 11 am UTC-5 = 10 am México ok :) great! see u then -- Bryan W. Berry Senior Engineer OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
