To begin with, I'd love to have someone working on a better OOM killer daemon than the default behavior the kernel provides. A fun project for the so inclined.
On Sun, 2007-10-28 at 16:19 -0400, Albert Cahalan wrote: > On 10/28/07, Jim Gettys <[EMAIL PROTECTED]> wrote: > > Albert, can you please see that there are proper trac entries fro > any > > leaking applications? > > I made one, #4471, for the activity I am aware of. > > I'm concerned about worse things, like data corruption. > Leaks and mere crashes are nothing in comparison. > Running out of memory makes allocations fail. When > that happens... > > Does JFFS2 corrupt itself? Reiserfs and ext3 have both > suffered from this problem. > The kernel *always* gets first dibs on memory, (it kills user space to get it). Jffs2 has been used for quite a few years on (much more) tightly memory constrained systems. It is the least likely to cause trouble. > Does the journal corrupt itself? I think it does, though I > certainly don't have decent proof yet. Create a big file, and see what happens. Bug reports with recipes greatly appreciated. > > Does a driver, in kernel or X, start a DMA to the wrong > location in memory? (address 0, a previous allocation > that has since been freed, or a clean page that was never > locked down and just got discarded by memory pressure) Not likely. > > BTW, there is also a need for power-loss testing. Do we > get corruption if we interrupt etoys/squeak or the journal > at a bad moment? Power loss will certainly happen. > This could use an automated test rig. > The hope/intent is normal shutdown on low battery. Apps get some warning. -- Jim Gettys One Laptop Per Child _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
