lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Overcommitable memory??
    On Tue, 21 Mar 2000, James Sutherland wrote:

    > >We are not short of memory. We're short of swap. paging-out is the problem,
    > >not paging-in.
    >
    > Where did you get that idea? This situation is "out of RAM+swap". No
    > RAM free, no swap free, nothing can be allocated. Nothing to do with
    > paging, either - you can shuffle the memory around fine, the problem
    > is just that there isn't enough to go round.

    We're saying the same thing: being out of swap implies being out of RAM.
    If you're not out of RAM, the swap area is *empty*. On a Linux system
    the swap space is almost never empty (unless it's 0-sized, of course)
    because the kerner thinks it's a better idea to page-out some unused pages
    to make room for more buffers/cache.

    But paging is not "shuffle the memory around": you go either RAM -> disk
    or disk -> RAM. In OOS situation, if a free page-frame is needed (because
    of a page fault wants to do a "disk -> RAM" operation), AND none is
    available (so it's OOM, after all), you first need to do a "RAM -> disk",
    which is impossible because swap is full. The problem occurs during
    page-out.

    > >> IMO, it's much better to get a signal which means "we're getting short
    > >> of memory, folks", which can be handled in ONE place, rather than
    > >> returning 0 as a pointer - which many apps then try to dereference,
    > >> ending up segfaulting themselves anyway.
    > >
    > >"many apps" do not check malloc() return values? I don't call them apps,
    > >I call them first time students exercises. B-)
    > >They're are not able to check malloc() return value but they can setup a
    > >signal handler that triggers runtime a GC() clever enough not to page
    > >fault itself? I don't follow you.
    >
    > If they don't bother handling errors of either sort, they just get
    > terminated with a signal anyway. If they are careful enough to check
    > malloc() every time, they would handle SIGBUS as well.

    So it doesn't make real difference. Everybody is used to write it's own
    safe malloc() wrapper. The problem is: you accessed some page of yours,
    and faulted. The kernel needs to page-in your data. To do that it needs
    a free page-frame (RAM). There's none. So it looks for an used page-frame
    that can be paged-out. It selects one. When it tries to page it out,
    it fails, 'cause swap is full. It kills a signal to you process.
    How can you be sure that your signal handler it there, *in RAM*, and
    won't page fault itself? Expecially if it runs some kind of garbage
    collector (which is likely to touch most of your data pages)?
    The whole problem arose not at malloc() time, but later when you're
    accessing your address space. A page that has been previously allocated
    to you (in RAM) when you wrote it, and later (you not being notified)
    paged-out to swap.

    >
    >
    > James.
    >

    .TM.
    --
    ____/ ____/ /
    / / / Marco Colombo
    ___/ ___ / / Technical Manager
    / / / ESI s.r.l.
    _____/ _____/ _/ Colombo@ESI.it


    -
    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:57    [W:2.340 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site