[olpc-software] graceful handling of out-of-memory conditions

[Jim Gettys]

I repeat: the desktop has way more information about what processes
matter to the user than the kernel does; and providing an ordered list
of processes to the kernel as input to the OOM algorithms is a simple
change to the current oom killer, simple for window managers to provide
and very likely to improve its behavior.  

Certainly my experience several years ago was the kernel OOM killer
didn't behave very well in practice in a somewhat similar environment,
and I know the Nokia 770 folks have also been finding it a problem and
have been experimenting, so I believe it is still seen as a problem in
more recent systems.

I'll be chatting with some of them at FISL, in a few weeks, I hope
(Nokia funds a research institute in Brazil, it turns out).

I think experimentation is in order, rather than speculation.  Given
that the entire oom_kill.c file is 370 lines of code, it hardly seems
that experimentation should be difficult.  There is nothing sacred about
kernel code. Even I have been known to muck around in kernels (though
not in Linux).  And there are many folks on this list who routinely do
so.

Let's shelve this discussion for a bit, until we have a better idea
which window manager we're going to run and can see how reality behaves,
and can do real experimentation.  Right now, we're waving hands at mach
2 on little first hand experience or data.
                         - Jim


On Tue, 2006-03-28 at 15:46 +0800, Jaya Kumar wrote:
> On 3/28/06, David Zeuthen <davidz at redhat.com> wrote:
> > I guess I'm just trying to say that... by default processes should be
> > protected from being nuked by the OOM killer in the kernel. When our
> > shell launches an application such as Firefox or Abiword it should
> > simply set a flag for that process such that the OOM killer in the
> 
> - any process on the system can be protected from the
> OOM killer by using /proc/pid/oom_adj and setting it to -17
> (OOM_DISABLE)
> 
> > kernel may nuke it. Child processes should inherit this flag of course.
> 
> - children currently inherit the oom disable flag.
> 
> > Hence, only apps that are not part of the "shell" may get nuked and this
> > should be sufficient as we already verified (through QA and testing)
> > that our shell isn't leaking.
> >
> > What about this simple low-tech solution? If it's not 100% stupid, I
> > suppose the next question is 1) what kernel changes are necessary; and
> > 2) can we expect the Linux kernel people to accept such a patch
> > upstream?
> 
> - oom killer selects the pid to murder by picking the pid that has the
> highest mem size ( mm->total_mm + (all of it's children's mem size/2))
> - long running + if_niced. this sounds nice and intuitive to me.
> - the core oom killer function is badness() here
> http://sosdg.org/~coywolf/lxr/source/mm/oom_kill.c#L46
> 
> I think the kernel already gives you the capability you request, right?
> 
> Best regards,
> jaya kumar
> 
> --
> olpc-software mailing list
> olpc-software at redhat.com
> https://www.redhat.com/mailman/listinfo/olpc-software
-- 
Jim Gettys
One Laptop Per Child