lkml.org 
[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some questions about linux kernel.
Den 15-Mar-00 04:02:09 skrev Horst von Brand følgende om "Re: Some questions about linux kernel. ":

>> > Is not vfork() solution to this particular problem?

> Not at all. vfork was a solution for the fork()+exec() case befor COW came
> around: The child used the parent's memory space until exec(2), to avoid
> copying it. COW (as today in Linux) gives you the same benefits (if not
> more), at less cost to the programmer.

Actually, COW has nothing to do with the question of overcommitting
memory or not. COW is a performance optimisation which works just fine if
you don't overcommit memory. As a side effect, COW may help to cover up for
missing RAM/swap if you overcommit memory, but that is just a side effect.

> OK, let's focus the discussion here:

> The problem with the current scheme is that a process can request memory,
> and get it granted; but that is no guarantee that it can _use_ the memory:
> If the system runs out, you might get a SIGSEGV (or SIGKILL) just by
> accessing a local variable that happens to be on a COW page which the OS
> can't copy for lack of space. Very unpolite behaviour, against which no
> program can sanely protect itself. The basic problem is overcommitment, the
> OS is promising memory in the hope it doesn't have to keep the promise.

Yes. What you're saying, really, is that a system which overcommits
memory doesn't have a working malloc(). And if I understood Alan Cox (?)
correctly, Linux overcommits memory somewhat even with
/proc/sys/vm/overcommit_memory set to 0. And it doesn't even have to be a
COW page that the poor program accesses when it is killed. Even a program
executing

while (1)
;

can become the victim of OOM killing.

> Trouble is, that in the Unix model each time your 400Mb emacs process
> fork(2)s it creates _2_ 400Mb processes (a responsible OS will have to make
> sure it has the spare 400Mb, just in case the child doesn't exec(2)
> anything smaller), the new process then exec(2)s ls(1), and most of the
> 400Mb reserve was for nothing. If you use vfork(2), you don't need 400Mb
> for the child process, true. But not every use of fork(2) can be replaced
> by vfork(2); in fact, most "interesting" uses can't.

vfork() can replace fork() in pretty much any variety of fork()/exec()
or fork()/wait(). This covers the wast majority of uses of fork(). The
exceptions, the "interesting" uses that you refer to, are rare, but have to
be supported, of course. I don't think anybody suggested that fork() should
be taken out of the kernel. fork() just shouldn't be used when vfork()
would work just as well or even better. Such as when your 12 MiB emacs
session wants to run 50 kiB /bin/ls.

Regards,

/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.dtu.dk |
| Please do NOT Cc: to me or the | WWW: http://www.gbar.dtu.dk/~c948374/ |
| mailing list. I am on the list.| "ThrustMe" on XPilot, ARCnet and IRC |
| If you wake up Sleepy & Grumpy, you must be Snow White. |


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