Messages in this thread | | | Date | 15 Mar 2000 17:57:19 +0100 | From | "Rask Ingemann Lambertsen" <> | Subject | Re: 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/
| |