Re: idea for running out of RAM
On Fri, Oct 31, 2008 at 9:24 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Albert Cahalan wrote: On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison [EMAIL PROTECTED] wrote: Could the oom-killer have a hook to enable this functionality to be invoked instead of simply killing the application? OOM is OOM. At that point, something needs to die. There is no escape from the cold hard truth that, once things have gone bad, it is too late for a good experience. Saving state will tend to cause OOM. When software does most anything, it needs memory. OOM is a particularly bad time to be trying to save state. Don't go there. I agree... which is precisely why we need the kernel to pause the offending allocation, and trigger a userspace program, while there are still (e.g.) 5 MB free. Call it a lowmem trigger. If the process of servicing the lowmem trigger hits OOM, then we're back to the standard behavior, but with an appropriately chosen buffer we should have enough room to close the memory-hogging activity instance without losing user data. This tends to fail horribly. Early detection of low memory is unreliable. Also, you have no idea if 5 MB is too much or too little unless you get some guidance from activities. Even if you succeed, you have failed. At best you have forced an activity to die, which is really not what the user would like. Most likely, you also get data loss. (because the system thrashes and the user cuts power, or because the activity doesn't implement an emergency save feature that can reliably operate from any program state, etc.) It's quite unlikely that the majority of activities will have a reliable and useful response to a low-memory signal. This is asking a lot from developers, even if you ignore all the less-sugary activities. Note that this notion is entirely compatible with per-activity memory limits. In fact, they seem to work quite well together. memory limits != memory reservations Memory limits create needless failure. Random user software can not be expected to have a useful response to memory allocation failures. The most you can hope for, and this is a great big **hope**, is that sudden death is non-corrupting. We have a problem with hitting the hardware memory limit. Adding an extra limit just increases the problem. Instead of continuing until the user gives up, a non-hardware memory limit causes an early failure. One might as well just ship less RAM if earlier failure is the goal! Memory reservations are a different beast entirely. Running out of memory becomes approximately impossible because the user is blocked from starting too many activities. Memory reservations mean this: Don't start something that you can't finish. or Don't bite off more than you can chew. or Don't make promises you can't keep. Memory reservations are fairly easy for everybody. You can implement them entirely in the program launcher. Activity authors don't need to write any code; they merely need to place a number in an activity.info file if they wish to participate. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Sucrose 0.83.1 Development Release
On Fri, Oct 31, 2008 at 9:30 PM, S Page [EMAIL PROTECTED] wrote: Simon Schampijer wrote: This is our first Development Release in the 0.84 cycle. The code base has seen many refactoring efforts to improve the platform. Will OLPC joyride builds pick up the new Sucrose? Sure. Hopefully soon. Furthermore the datastore has been rewritten, to simplify and improve maintainability. The API has been kept in place. What happens when you upgrade an XO with the old datastore? The old datastore will be updated to the new format. What happens if you then downgrade it? You lose. Sugar moved to use Gconf as a back end to store the profile. When you upgrade an XO, does it import your old profile (~olpc/.sugar/default/config)? Yup. What happens if you then downgrade? You will be prompted to enter again a name, choose a color, etc. An ABI policy has been figured out and modules have been marked as STABLE / UNSTABLE / DEPRECATED. Where are they marked, in the .py files? Yes, in the docstrings so it should make it to places like http://api.sugarlabs.org == Fructose news == ... Are the new activity versions backwards-compatible with 8.2? If so, the maze of Activity lists should be updated. Most of them yes, a notable exception is Browse because depends on xulrunner and hulahop. Read has the same issue, but evince hasn't been updated (yet) so for now it should work. Currently http://wiki.laptop.org/go/Activities/Joyride pulls in Activities/G1G1 , as does Activities/G1G1/8.2, and that list still references old versions -- Browse 98 not 100, Read 52 not 60, etc. -- even though the links say Browse (latest). Who could take care of this? Full Release Notes: http://sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.83.1 Maybe you could address these questions in a ==Compatibility== section in the release notes. Yes, I agree this is an important issue that should be given greater relevance in the release notes. The changes and fixes sound excellent! More coming! Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC France CodeCamp in Paris
This sounds very interesting and useful. A nice breadth of projects to keep things interesting and cross pollinate ideas between groups that might not interact frequently. thanks david 2008/11/1 LASKE, Lionel (C2S) [EMAIL PROTECTED] Hi all, OLPC France is proud to announce its OLPC CodeCamp in Paris on November 15 th. Five workshops are planned: · Sugar: development and experimentation on Sugar/python, · School Server: setting up and test of school server on multiple platform (standard PC, Booba server, CherryPal, …), · Mono: development of new activities using Mono, · Pedagogic usage: Feedbacks from Haïti, Ethiopia and Palestine deployment. Brainstorming with French teachers to find usage and class activity for the XO. · French localization: French translators will work all the days to translate in French, sugar, activities and FLOSS manual. If you're interested to meet the French OLPC community and to have a nice trip to Paris: you're welcome ! More information on: http://olpc-france.org/wiki/index.php?title=OLPC_France_CodeCamp_15_november Best regards from France. Lionel Laské ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Cahalan wrote: Memory reservations are a different beast entirely. Running out of memory becomes approximately impossible because the user is blocked from starting too many activities. This seems like a silly statement to me. Almost every activity on the XO is capable of exceeding the hardware memory limit all on its own. Per-activity memory reservations are also per-activity limits, and they are only safe if those limits are set higher than the maximum amount of memory required by that activity, and that maximum value is simply far too large. I like the idea of memory reservations, and they were part of the original design, but if we set them high enough to be safe, we would have a single-tasking (and maybe zero-tasking!) operating system. I should also be clear that I don't think Activities should receive the low-mem signal. I think Sugar should catch the low-mem signal, so that it can attempt to do something smarter than the OOM killer because it knows much more about the system. For example, it can choose to kill the activity instance that is using the most memory, or the least-recently-used activity instance, or even the instance that has most recently saved its state. This works especially well if we also use the knobs on the OOM killer. For example, the low-mem signal, after pausing all other processes, could cause Sugar to (1) select an activity to kill, (2) set that activity's oomadj parameter to make sure that it will be the first one killed if we hit OOM (3) ask that instance to save its state to the datastore, (4) close the activity instance, and (5) pop up a notification to the user about what just happened. The cgroups stuff could also help here, since the OOM killer by default thinks in terms of processes, but each Activity can be multiple processes. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkMb2MACgkQUJT6e6HFtqR1SACfafFkA4mYsuasPypMasU1LxN0 QoQAnjUbvkbvAgpQ++5SJDJS1ng5CFjj =uQeu -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ec battery commands
On Sat, 01 Nov 2008 16:39:49 -0400 Paul Fox [EMAIL PROTECTED] wrote: hi dilinger -- one of the tasks on the EC punchlist is this one: Make battery commands return 0xff (or some other invalid value) if the battery is not present. This will be an error indication for the kernel. can you point me at the kernel code that cares about this, and, in particular if you can remember, for which commands it's most important to have this behavior changed? i'd like to be sure i understand the req'ts before implementing anything. Certainly; the specific code is drivers/power/olpc_battery.c. The code that is acutally querying the battery status is olpc_bat_get_property(). Due to the current limitations of the API, we cannot simply fetch EC_BAT_ACR; every value is valid, and (aiui) the EC will simply return the last known value. This is undesirable if there's no battery present, so we currently first check EC_BAT_STATUS (for PRESENT), and then run the necessary EC command. This means that each query ends up running 2 EC commands. It would be nice to cut that down to 1. Along those lines, it would be nice if there was an error value that we could check for if the EC thinks that there is no battery present, and we run some random command that is querying for battery info. Richard and I discussed this a bunch a long time ago, but it was in person and my memory is fuzzy.. I don't remember if we came up w/ a value that would work across all EC battery commands. It would kind of suck if we had to have different error codes for different commands, but that would still be better than our current behavior. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
Or, as I found out, if you have the developer key on a pen drive, you can boot into debxo from that, and copy develop.sig into /boot/security/, and have security enabled and debxo at the same time, should you want to. Thanks, all. I'll see what I can do about creating a wiki page if there isn't one already. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
kawk wrote: Or, as I found out, if you have the developer key on a pen drive, you can boot into debxo from that, and copy develop.sig into /boot/security/, and have security enabled and debxo at the same time, should you want to. Thanks, all. I'll see what I can do about creating a wiki page if there isn't one already. http://wiki.laptop.org/go/Activation_and_developer_keys already had this information about recovery when you lose develop.sig. I reorganized it into a If you wipe out your developer key section. There's a http://wiki.laptop.org/go/DebXO page, edit away. Regards, -- =S Page ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
