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

[Jaya Kumar]

On 3/28/06, Jim Gettys <jg at laptop.org> wrote:
> 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.

I am not sure but you might have interpreted my elaboration about OOM
as a remark for/against window manager/kernel OOM ordering. It's not.
I merely wanted to share how the kernel currently does OOM handling.
:-)

I should elaborate further, let's say you wanted to have the window
manager provide an ordered list ranked in order of attractiveness for
OOM culling. (as you described above). So you have a list of pids,
1001..1008. If OOM occurs, you want 1008 skewed for culling much more
heavily than 1001. You can do that by having the windowmanager
essentially do:

echo 1 > /proc/1001/oom_adj
echo 8 > /proc/1008/oom_adj

This skews "1008" 8 orders heavier than the average process in favour
of culling because points <<= p->oomkilladj;

This should allow the window manager to effectively segregate processes.

> 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.

I definitely agree. I hope nothing I said reflected otherwise.

>
> 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.

I agree. I hope, though, that the technical part of the discussion is
helpful in some way.

Best regards,
jaya

>                         - 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
>
>
>