Re: idea for running out of RAM
On Sat, Nov 1, 2008 at 11:01 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: 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. If so, then most are broken. Tux Paint doesn't suffer from this defect. The only semi-respectible excuse is that the activity accepts arbitrary input. The web browser is the obvious example. It's only semi-respectible because the activity can often have an internal limit (enforced in the easy code paths) for this, and because partial document rendering can prevent activities like Read from having this problem. If the activity can not be modified to limit itself, then it can't legitimately specify a reservation. Sugar can make these badly behaved activities run by themselves. 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. The difference is that activities never get killed under a reservation system unless one is malicious or horribly buggy. Under a limit system, activities will die. It's unacceptable. 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. No, although there are massive usability advantages for the elimination of being able to run multiple things at once. When a kid runs multiple activities, 100% of the time it was unintentional. The kid got confused, probably because the damn frame popped up under his mouse and stole a click. 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. Destroying the user's work by killing an activity: FAIL 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. In a fit of rage, the kid throws his XO out the window. It just ate his work for the eleventy-seventh time today. Lots of things are wrong with that. You may kill an activity that could have survived; there is no good way to tell when OOM will be hit until you hit it. Setting oomadj doesn't prevent the laptop from getting so slow that the user decides to hard reboot. There is no reasonable way to ask an activity to save state. People don't write perfectly modeless code with atomic operations on a database. Since we can often determine an upper bound for the RAM usage of an activity, we can trivially determine if a given set of activities is capable of causing OOM. If we determine that starting a new activity would place the XO in danger of OOM, then there is no excuse for allowing that activity to start. 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. That would cause activities to die. Work is lost. FAIL ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On 2 Nov 2008, at 06:07, Albert Cahalan wrote: On Sat, Nov 1, 2008 at 11:01 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: 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. If so, then most are broken. Tux Paint doesn't suffer from this defect. The only semi-respectible excuse is that the activity accepts arbitrary input. The web browser is the obvious example. It's only semi-respectible because the activity can often have an internal limit (enforced in the easy code paths) for this, and because partial document rendering can prevent activities like Read from having this problem. If the activity can not be modified to limit itself, then it can't legitimately specify a reservation. Sugar can make these badly behaved activities run by themselves. 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. The difference is that activities never get killed under a reservation system unless one is malicious or horribly buggy. Under a limit system, activities will die. It's unacceptable. 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. No, although there are massive usability advantages for the elimination of being able to run multiple things at once. When a kid runs multiple activities, 100% of the time it was unintentional. The kid got confused, probably because the damn frame popped up under his mouse and stole a click. 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. Destroying the user's work by killing an activity: FAIL 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. In a fit of rage, the kid throws his XO out the window. It just ate his work for the eleventy-seventh time today. Lots of things are wrong with that. You may kill an activity that could have survived; there is no good way to tell when OOM will be hit until you hit it. Setting oomadj doesn't prevent the laptop from getting so slow that the user decides to hard reboot. There is no reasonable way to ask an activity to save state. People don't write perfectly modeless code with atomic operations on a database. Since we can often determine an upper bound for the RAM usage of an activity, we can trivially determine if a given set of activities is capable of causing OOM. If we determine that starting a new activity would place the XO in danger of OOM, then there is no excuse for allowing that activity to start. 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. That would cause activities to die. Work is lost. FAIL Just to chime in on this thread, the 4 conditions that I have (knowingly) encountered OOM in order of importance (personal opinion) are: 1) Read (when zooming in several or more times, zooming on a map is a good use case) 2) Browse (large pages, or long usage, using Google reader for ~20min is a good use case) 3) olpc-update (used to OOM often but seems much better now that 8.2 is final, hoping this is resolved) 4) Control Panel - Software Update (used to OOM often but seems much better now that 8.2 is final, hoping this is resolved) I do think it's still way to easy to double click, or re-click, to multi-launch/resume an activity due to the laggy launch screen appearance (there's plenty of floating trac tickets about this still), but it is much better than it was during some of the 81 unstable dev cycle. However, ** as an adult **, I rarely encounter OOM due to launching too many activities –
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: 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: idea for running out of RAM
On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison [EMAIL PROTECTED] wrote: Did you continue down this path (auto-saving application state to NAND when we run out of memory)? How tenable is the idea of saving application state to NAND on our system? 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. The focus needs to be on prevention. I welcome something better than RAM reservations, but I'm not expecting anything better. IMHO, implementing the best known option would be a good move. ___ 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: On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison [EMAIL PROTECTED] wrote: Did you continue down this path (auto-saving application state to NAND when we run out of memory)? How tenable is the idea of saving application state to NAND on our system? 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. Note that this notion is entirely compatible with per-activity memory limits. In fact, they seem to work quite well together. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkLBygACgkQUJT6e6HFtqSoxwCfdkrCjBJ2RnJFYSt6MjKAsxw8 0k0An14GSYnyJ3PYa0UulLV7Yri18pMG =tzc6 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Oct 30 2008, at 10:05, Erik Garrison was caught saying: Deepak, Did you continue down this path (auto-saving application state to NAND when we run out of memory)? How tenable is the idea of saving application state to NAND on our system? No I haven't. :( Could the oom-killer have a hook to enable this functionality to be invoked instead of simply killing the application? Yes, the question is what is the proper interface back to user space. In talking to some upstream kernel developers,this type of interface has been desired by others but nothing has been accepted upstream. Next step in this process is research what has been proposed so far, why they've all failed, and figure out what we want to do. One such interface is proposed at http://lwn.net/Articles/267013/. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Mon, 29 Sep 2008, Hal Murray wrote: One would adjust the shading in each activities portion of the circle. White for not used and black for used. (Red for over allocation?) The other would be to use the applications chunk of the circle as a pie shaped bar graph. The black section would show what % of the allocated memory was currently in use. Maybe a ring with shared memory protruding inside and allocated but not-paged-in memory protruding outside? -- Alex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Mon, Sep 29, 2008 at 2:07 AM, Walter Bender [EMAIL PROTECTED] wrote: So UI changes that help make this clearer will probably be a good idea for a 9.1 ... :-/ There was an early sketch of a mechanism similar to the old Home View circle, where there was a space allocated to each open activity proportional to the amount of memory it was consuming. In any case, it is just as easy to make a bar graph as a pie chart... Dan Winship explained the issues with this approach here: http://wiki.laptop.org/go/Activity_ring . Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
Note that more current Linux kernels, such as that in 8.2, are much better at being able to account for what process is using what memory. It's probably worth a little experimentation after 8.2 ships to see if the original concept is now viable. - Jim On Mon, 2008-09-29 at 10:06 +0200, Tomeu Vizoso wrote: On Mon, Sep 29, 2008 at 2:07 AM, Walter Bender [EMAIL PROTECTED] wrote: So UI changes that help make this clearer will probably be a good idea for a 9.1 ... :-/ There was an early sketch of a mechanism similar to the old Home View circle, where there was a space allocated to each open activity proportional to the amount of memory it was consuming. In any case, it is just as easy to make a bar graph as a pie chart... Dan Winship explained the issues with this approach here: http://wiki.laptop.org/go/Activity_ring . Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Mon, Sep 29, 2008 at 6:04 PM, Jim Gettys [EMAIL PROTECTED] wrote: Note that more current Linux kernels, such as that in 8.2, are much better at being able to account for what process is using what memory. It's probably worth a little experimentation after 8.2 ships to see if the original concept is now viable. I think a memory usage pie graph is beyond excellent. I'm not so sure it should show current usage though. It probably should show maximum expected usage, based on previous behavior and/or RAM reservations. The point of a pie display is to show the user how much of the machine is occupied. If an activity is using 12 MB now but will likely need 34 MB, then that extra 22 MB is definitely not available for running other stuff. Things work out nicely this way. The user can see why the OS is refusing to let him start more activities. The minimum activity size (for the icon) is no problem; it is simply the minimum RAM reservation. If the pie graph is exclusively based on RAM reservation, then there isn't even any need to mess with /proc data. An interesting extension of the idea would be to mark activity icons (or their hover menus) with pie fragments. This would let the user know in advance if an activity would be unstartable, and would let the user know how much he needs to free up to resolve that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
I think a memory usage pie graph is beyond excellent. I'm not so sure it should show current usage though. I'm assuming that each activity gets allocated a chunk of the pie corresponding to how much memory it asks for. How about using part of the circle to show the fraction of memory allocated but not used yet? Say by using the circle from 1-inch dia to 1.25 inch dia. I can think of two ways to do this. One would adjust the shading in each activities portion of the circle. White for not used and black for used. (Red for over allocation?) The other would be to use the applications chunk of the circle as a pie shaped bar graph. The black section would show what % of the allocated memory was currently in use. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Thu, Sep 25, 2008 at 2:20 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 25 Sep 2008, at 01:00, Martin Langhoff wrote: From your experience are your newcomers accidentally or intentionally launching too many Activities? Is it that they genuinely wanted to have N activities all running at once? I guess I'm thinking Eben's existing design proposal for adding recent Journal activities to the Home view icons will solve the accidental cases, but that intentional use (where the user does not understand - and most don't - resource usage) will still bite novice users until they've had their fingers burnt enough times. Accidental - it's very hard to get a picture of how many apps are running - there is no differentiation in the top of the frame between the 3 things that appear there: - 4 icons for zoom levels / modes - 1 icon for a magic activity: journal - N icons for open apps so I haven't spotted anyone discovering that N means how many apps are open. (Given enough time and engineering-minded types, they will, but it's not that easy...) So UI changes that help make this clearer will probably be a good idea for a 9.1 ... :-/ cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Thu, Sep 25, 2008 at 3:57 PM, John Gilmore [EMAIL PROTECTED] wrote: PS: We don't even know the mem footprint of our activities. It all gets jumbled up by Sugar and Security and other changes. Nobody thinks the numbers in top are useful, nobody has any better way to measure the mem footprint of an activity. Nobody to the left, nobody to the right. Google this archive for ps_mem.py for the tool you are looking for - might need a tweak to separate python instances out, but it's trivial :-) m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Wed, Sep 24, 2008 at 5:18 PM, Bobby Powers [EMAIL PROTECTED] wrote: setting RAM requirements reminds me of classic macos :) Indeed. And quite fitting - classic macos is the most recent (and memorable) case of no swap multi-tasking OS we have. Granted, it *had* a broken vmem scheme, but in practice... I agree with Albert's proposal - Newcomers to the Wellington test team open too many apps all the time - and render their machines unusable through memory pressure. From that experience, I like the idea of adding a bit of metadata that hints the mem footprint, and teaching sugar to prevent users from starting new apps if less memory than stated is available. Not a hard limitation - power-users must be able to disable it from the control panel. In that sense, it'd be great to bring back the visual cue of memory use that was disucssed back then with the original ring in the homeview. The ring is gone, but _some_ visual hint would help users make the connection. Forcing a single app at a time is a bit too limiting I suspect. And our hw does better than that anyway. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On 25 Sep 2008, at 01:00, Martin Langhoff wrote: I agree with Albert's proposal - Newcomers to the Wellington test team open too many apps all the time - and render their machines unusable through memory pressure. From that experience, I like the idea of adding a bit of metadata that hints the mem footprint, and teaching sugar to prevent users from starting new apps if less memory than stated is available. From your experience are your newcomers accidentally or intentionally launching too many Activities? Is it that they genuinely wanted to have N activities all running at once? I guess I'm thinking Eben's existing design proposal for adding recent Journal activities to the Home view icons will solve the accidental cases, but that intentional use (where the user does not understand - and most don't - resource usage) will still bite novice users until they've had their fingers burnt enough times. Many years back, I used to help support ~100 staff at an Adobe office running the mid to late MacOSs. Resolving crashes due to incorrectly set memory defaults was pretty high up on the list of constant daily issues and user education. I'd say it was a major support issue (but below flakey 3rd party start-up extensions, and corrupted preference files). Oh happy days... --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Wed, Sep 24, 2008 at 9:20 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 25 Sep 2008, at 01:00, Martin Langhoff wrote: I agree with Albert's proposal - Newcomers to the Wellington test team open too many apps all the time - and render their machines unusable through memory pressure. From that experience, I like the idea of adding a bit of metadata that hints the mem footprint, and teaching sugar to prevent users from starting new apps if less memory than stated is available. my 2 cents or less. I see the same. Kids will not bother stopping activities and they will pile up, so any of the ideas in this thread will probably help. A visual cue might be easier to implement and also more educational. My feeling is that kids will quickly understand that a resource (memory in this case) is limited. Cheers! Ricardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
I agree with Albert's proposal - Newcomers to the Wellington test team open too many apps all the time - and render their machines unusable through memory pressure. From that experience, I like the idea of adding a bit of metadata that hints the mem footprint, and teaching sugar to prevent users from starting new apps if less memory than stated is available. We can slap a crutch like that onto the system, but we actually built and shipped a release (703) that did let you run three or four activities without serious trouble. That release is in the field, and people will expect to still be able to run three or four activities after upgrading to the new release. In theory, releases get better rather than worse. Our old release also took quick corrective action when it ran out of memory -- it rapidly killed off some program, often the largest one. Our new release doesn't do that, and nobody knows why. Instead it just gets really slow and groggy. It seems to be a kernel change, but nobody's bisected it. See http://dev.laptop.org/ticket/8316, for example. Rather than putting work into crutches, let's fix the real problems that we already know we have. John PS: We don't even know the mem footprint of our activities. It all gets jumbled up by Sugar and Security and other changes. Nobody thinks the numbers in top are useful, nobody has any better way to measure the mem footprint of an activity. So even assuming that you added a field to every activity, what values would you put in those fields? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Sep 23 2008, at 03:40, Albert Cahalan was caught saying:
Determining the RAM requirement for an activity goes something like
the following:
awk '/Dirty/{x+=$2} END{print x}' /proc/12345/smaps
(after exercising all functionality)
I like the idea overall but this part worries me. An activity such
as etoys has a lot of functionality.
We can refine that, remembering that it will never be perfect.
Adding a bit more (5 megabytes?) to avoid the slows is important.
If an activity has lied, there isn't much that can be done. Oh well.
If the lie is caught before the system gets horribly slow, the OS
can simply increase the reservation for that activity. (either just
for that session, or persistently) The OS can log the problem, allowing
the activity developer to be flamed. Killing the lying activity is not
a good option, but it could be done, especially if some other activity
is already running. Once the slows hit, it's back to the power button.
BTW, the alternative is far more harsh yet easier for kids to deal with.
We just ditch the whole idea of letting activities run concurrently. :-)
Seriously, consider it. We're really short on RAM, and activity switching
is not at all easy for kids.
I've been thinking to myself that this might be the right approach. While
we may think of that as limiting, for a child who has never used a computer
before, it might help focus their attention and be less confusing to
simply allow one instance of any activity to run.
We can also play tricks like saving state of an activity to flash on
alt-tab and quickly restoring it when tabbing back. This is common
in the mobile space where we want an illusion of being able to switch
between running applications. Your cellphone will most probably
never crash due to OOM, but you can often run multiple applications
on it. This won't work with shared activities or activities that
have any network sockets open, but for purely local applications
it should be do-able (though non-trivial).
Something else I am looking into for helping with memory on 8.2.1 and
9.1 is compressed caching. We can still OOM with this, but my experience
with my little playing I've done with it is that it drastically helps
keep the system useable as memory footprint increases.
~Deepak
--
Deepak Saxena - Kernel Developer - [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
At Tue, 23 Sep 2008 10:57:36 -0700,
Deepak Saxena wrote:
On Sep 23 2008, at 03:40, Albert Cahalan was caught saying:
Determining the RAM requirement for an activity goes something like
the following:
awk '/Dirty/{x+=$2} END{print x}' /proc/12345/smaps
(after exercising all functionality)
I like the idea overall but this part worries me. An activity such
as etoys has a lot of functionality.
For Etoys, the memory usage grows only when you load a project or
instanciate widgets (give or take, when you display a compressed
bitmap, it expands automatically and eats more memory, etc.). So,
about it will be 30MB and it will stay flat whatever you do. We can
reduce the base size, if that is the priority.
-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Tue, Sep 23, 2008 at 3:40 AM, Albert Cahalan [EMAIL PROTECTED] wrote:
For the zillionth time, my kids brought my XO to a halt. They started
up two copies of Tux Paint and two copies of Colors! (BTW, boy do I
hate names with built-in sentence-ending punctuation) The end result
is that the activities die (unacceptable), usually via power button.
There are a number of different problems here. It's a UI defect that
the kids lose track of what is running and feel a need to start things
that are already running. Kids don't think I **switched** back to the
home screen. Instead, they seem to think the activity suddenly died.
It's another UI defect that they are getting switched away from the
activity at all; I'm quite sure there is no intent to go to the home
screen. It just happens randomly, being not very kid-friendly.
Intentional or (more likely) not, the kids get too many things running.
In theory the kernel will kill things as a last resort, which is awful,
but it doesn't happen because the user won't wait (hours? days?) for it.
Fully solving the problem is impossible, but we can do a lot better.
First let's rule some things out:
* the slow hang we have, causing loss of work via power button
* OOM, causing loss of work via actively killing stuff
* rlimit, causing loss of work via allocation failure
* activity grabs RAM up front, leading to one of the above
The commonality here is that, once started, an activity must never
be bothered with a memory shortage.
We can cover nearly all cases with RAM reservations. Worrying about
the other cases is not productive. Activities can lie about how much
RAM they will use. The OS itself may unexpectedly consume RAM. Again,
a perfect 100% solution is impossible but we can do a decent job.
RAM reservations go in activity.info files. They let sugar know
when to stop letting the user start new activities.
Suppose we have 256 MB, the OS consumes 176 MB, and 80 MB is left.
Activity X declares a need for 60 MB, activity Y declares a need
for 20 MB, and activity Z declares a need for 30 MB. Activities
P and Q do not declare anything. The user may thus run any of:
X
X,Y
Y,Y,Y,Y
Y,Y,Y
Y,Y
Y
Z
Z,Z
Z,Z,Y
Z,Y,Y
Z,Y
P
Q
P,...,P,Q,...,Q (unlimited) -- optional
If we allow that last option, then activities P and Q are unprotected
in every way. Any number of them can run at the same time. Crashing is
far more likely, which is bad, but existing behavior is preserved.
Note that activities which declare a RAM requirement will never run at
the same time as activities which do not. If this is allowed, then any
activity that fails to declare a RAM requirement will endanger data in
the well-behaved activities. It's an option, but a rather awful one.
ugh, I know this is a frustrating area in general, but how
easy/intuitive is it for kids if they are running one activity for
another activity to fail to launch because it has (or doesn't have)
RAM requirements listed?
setting RAM requirements reminds me of classic macos :)
bobby
To be clear: after starting 4 copies of activity Y, sugar must refuse
to start any more. It's simply not allowed, since doing so is likely
to lead to data loss.
Not every activity can declare a RAM requirement. I happen to know that
Tux Paint is fairly well behaved; it does not grow without bound.
I strongly doubt that Browse is well-behaved or ever could be.
Determining the RAM requirement for an activity goes something like
the following:
awk '/Dirty/{x+=$2} END{print x}' /proc/12345/smaps
(after exercising all functionality)
We can refine that, remembering that it will never be perfect.
Adding a bit more (5 megabytes?) to avoid the slows is important.
If an activity has lied, there isn't much that can be done. Oh well.
If the lie is caught before the system gets horribly slow, the OS
can simply increase the reservation for that activity. (either just
for that session, or persistently) The OS can log the problem, allowing
the activity developer to be flamed. Killing the lying activity is not
a good option, but it could be done, especially if some other activity
is already running. Once the slows hit, it's back to the power button.
BTW, the alternative is far more harsh yet easier for kids to deal with.
We just ditch the whole idea of letting activities run concurrently. :-)
Seriously, consider it. We're really short on RAM, and activity switching
is not at all easy for kids.
___
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
