[lkml]   [2000]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Overcommitable memory??
    On Sat, 18 Mar 2000, Mike Castle wrote:
    >On Fri, Mar 17, 2000 at 10:52:55AM -0600, Jesse Pollard wrote:
    >> Just doing this does force the administrator to give a very large amount
    >> of swap space to the system. Currently, there is no way to tell fork not
    >> to make such reservations (but only sometimes...). If the desired sequence
    >vfork() ?

    vfork is one way to do this. It has been rejected, parially I believe, because
    it didn't get included in various standards - vfork itself is a BSD base,
    and I haven't seen it in anything else. For most purposes, fork is equivalent.
    The other reason is that most applications do not implement/use vfork since it
    wasn't part of the majority of UNIX versions. This made portability of vfork
    an issue with applications. Since fork accomplished the same thing, it was

    Problems with fork overallocating memory didn't occur until after large
    processes became the norm. Programs using X, the more recent (last 10-15 years)
    applications and databases tend to use large processes. Fork now causes
    problems by having to reserve the entire user data space. Doing this in
    the places where vfork would have sufficed causes a process to nearly double
    the memory requirement. Large applications like emacs, which try to store
    the entire data file in memory, cause major problems.

    I think that most of these cases could be handled by a delayed reservation
    (I do see the disadvantages too). This would give the child process time
    to perform an exec - which allows the delay to emulate a vfork.
    Jesse I Pollard, II

    Any opinions expressed are solely my own.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.020 / U:32.640 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site