[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.111 / U:2.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site