Re: OOM band-aid

Ely Wilson (plexus@ionet.net)
Thu, 8 Oct 1998 12:42:52 -0500 (CDT)


> (Just my humble opinion of course, however...)
>
> runs a big arbitrary graph-structured-dynamic-systems simulator that
> really needs a ton of memory, you're going to end up killing that for no
> reason other than that it uses a lot of memory.
>
> This seems to me a sort of poking at it with a stick blindfolded solution.

I'm not alone.

> You can still get to the point where you run out of disk space on your
> designated failsafe dynamic swap file partition, of course, but in between
> having to initially create that file and when it runs out of disk space
> there is a potential large measure of additional protection over the
> more draconian approaches.
>
> I'm not suggesting that anyone abandon good ideas for currying caches and
> so on, just suggestion a less scatter-shot approach to the worst case
> out-of-normal-memory situation.
>

I still like the fact that people are running aroudn going 'kill the bad
process' like the ieda of the kill is good, which it is not. YOu can't
just kill a process because it tries to use memory that is not there.
This is why I asked afore why xalloc() does not just return null and the
processes handle it from there.

And I get a 'well on some instances the memory may be requested but never
used'.

I think that with that something is seriously wrong. Why on earth woudl
someone design a program to request memory it will never use?

And then there's the 'evil process' scenario, where some user maliciously
eat all memory on the system. There should be a failsafe protecting the
system from a malicious userspace program. Is't there already.

Other than that, if you don't have the blessed memory, you obviously need
more.

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