RE: Overcommitable memory??

From: David Schwartz (davids@webmaster.com)
Date: Fri Mar 24 2000 - 17:43:13 EST


> On Thu, Mar 23, 2000 at 02:54:49PM -0800, David Schwartz wrote:
>
> > malloc starts to fail, I'd happily use it. On Linux, I don't even have
> > malloc failing. And on no platform do I have a good way to
> > detect when I'm
>
> Just to clear up my understanding, are you saying that malloc() does not
> fail under linux for you? I realize that it is possible for it to promise
> you memory that it can not give you, but in practice I have found that it
> does return NULL when the system is out of memory.
>
> Jim

        Unless you set resource limits, 'malloc' does not fail until it's way too
late. By the time 'malloc' fails, you are swapping so badly that performance
is already toast. You then get into a spiral where the low performance
causes more inbound and outbound data to back up in the application's
queues, this increases the memory demand, increasing paging/swapping
further. While I can at least detect this condition and work on it, I'd
prefer to avoid it entirely.

        If 'malloc' had failed earlier, that would have given me plenty of time to
redirect load. The only two solutions currently available that I know of are
providing very little swap (ugh) or using gestappo resource limits to avoid
swapping (ugh).

        But again, this has nothing to do with overcommitting. What is needed, IMO,
is some way to judge how much memory pressure the system is under.
Unfortunately, low physical memory free and high amounts of swap in use
don't tell us this. You could measure things like hard page faults per
second, but it's hard to decide how much is too much in anything remotely
resembling a portable, reliable way.

        NT, for example, tends to fail mallocs (and some system calls with ENOMEM
or ENOBUFS) when under memory pressure. I used to consider this a bug, but
if you have a good OOM handler in your program (as we do), this is a
blessing. It gives you that early warning you need to give you time to deal
with the problem before it becomes fatal.

        DS

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



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:14 EST