[lkml]   [1997]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Memory overcommitting (was Re:

    In message <>, John Wysz
    ynski writes:

    > Thanks to all who have lobbed missiles at me, especially those who believe
    > that they known all that can be known. I simply cannot respond to them all.
    > If this method of allocating memory is indeed as wide spread as some have
    > claimed, it hasn't been going on as long as some of you "experts" claim.

    Then show us which system in the past did it better, and how we can modify
    the current kernel to handle the new idea.

    About the only thing ``better'' would be to have enough silicon for each
    program to have everything it could possibly need, all to itself. In
    the absence of that, you have to come up with a scheme that satisfies
    the various cases as best it can. Alternatively you could make sure
    your program will FIT in the system you have to run it on.

    Most of what you are talking about is characteristic of resource
    allocation systems. Such systems are never perfect, they cannot be.
    They exist because of imperfection: limited resources. Some handle it
    better than others. I'm not sure Linux is the best, but it is pretty
    good in most cases.

    > It may be the explanation why in the last few years I have seen so many
    > programs die for no cause in the middle of the day. (On non-Linux systems

    If there was no cause, then why did they die?

    I'm betting on two reasons: programming error or a program too big for
    the chosen system.

    > so far.) In an operational environment, such havoc is not appreciated.

    Name one where such things don't happen. I'm willing to be if you
    know of one, it will be one where a brute-force approach was used.
    Works great if you have the resources. Otherwise, you have no choice
    but a resource allocation system that will fail under some conditions.

     \ /
      Last update: 2005-03-22 13:39    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean