low-memory testing

[Jim Gettys]

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 <jg at laptop.org> 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