RE: Overcommitable memory??

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

  • Next message: Alan Cox: "Re: Avoiding OOM on overcommit...?"

    > 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 24 2000 - 18:15:19 EST