lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Memory hogs
Date
From
> On Sat, 17 Jul 1999, Hermann Schichl wrote:
> > Werner Almesberger wrote:
> > > > Hermann Schichl wrote:
> > > > I think it would be great if OOM handling would be
> > > > configurable (either kernel compile time or /proc interface)
> > >
> > > Better yet, have a device or proc file that becomes readable in this case.
> > > Then you can have a user-space demon to implement whatever policy you like.
> >
> > Yes, I think this is the cleanest idea. And it could be expanded
> > to most limit-exceeding situations (num of processes,...).
>
> Once you get out of memory, there is no clean solution.
>
Of course not. But proper OOM handling does not start when
you are out of memory. Instead it starts when memory is very tight,
because this is when the machine starts to get unusable anyway.
>
> Putting the bloat in userland doesn't mean there is no
> bloat -- the additional overhead will probably just
> 'uglify' the problem.
>
True, too. However, this is not what I wanted to say. The point
is (and probably this is what Werner wanted to tell me) that
configurability and fancy stuff should go into userland. We need
proper REAL OOM (when NO memory is left) handling in the kernel
and it should be stateless, fast and failsafe.
>
> My solution works rather well so I don't see why there
> are so much objections to it again...
>
I have no objections if we use your solution for the REAL OOM
case. However, I would like to see configurability and the ability
to have manual influence added. Userspace with a nice kernel interface
to handle NEAR OOM situations would be nice.

The reason is that your solution cannot guarantee that the most important
process on my system is not killed, since it does not know what the most
important process on my system is.
>
> We've had this whole discussion just before the 2.2pre
> era, when I decided the kernel should stabilize and my
> patch wasn't important enough to disturb the debugging.
>
> I propose we stop this discussion until somebody produces
> better CODE then what's in my patch.
>
No, we should not stop discussion. And I don't see why you always
think that I think that the code you are proud of should be replaced.
I hope that we can add something to provide a kernel interface (or
whatever) to make reaction to NEAR OOM situations more flexible.

Just imagine that your compute server runs two calculations for NP-hard
problems (you cannot easily guess in advance what the required amount
of data will be); they run for ten days. Then the combined memory requirement
(almost) exceeds your VM size. If one of them gets killed - SHIT! I'd
prefer to stop them both, add a few more MBs of swap space, how ever, and let
one of them continue. If it has finished let the other one continue and
save a few days....
>
If I had time, I would produce this additional CODE. But, I have not read
much of the kernel sources after the late 0.99s, and I would prefer if
somebody could do it who has more insight. This is why I made the suggestion
in the first place, and this is the reason for the discussion. If, after
the discussion, it is decided that additional flexibility is a Bad Thing(TM)
nobody has to spend time to produce any sort of CODE.

Hermann



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.045 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site