Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
That frood Jerry Feldman sassed: > I was generalizing, and yes I am sure. They use the page tables and mark > them as copy-on-write, so that when they get modified, the appropriate copy > is made. That makes the fork operation very fast, and there is very little > penalty paid by fork()/exec(). So: > pid = fork(); > if (pid == 0) { /* child */ > exec(.....); > } > In the above case, assuming pid can be held in a register, there is no > modification of the data segment, so none of the data segment pages need to > be copied. Once the child tries to write to a variable in the data > segment, then the page which holds that variable is duplicated. Interesting... I wouldn't have guessed this strategy. Which I suppose is at least partly why I'm not a kernel hacker! :) But I was thinking about your comments as pertains to the original poster's question about whether or not the OS keeps copies of dead applications' pages in memory to speed up future loads... >From a user's perspective, most processes are started by their login shell (or a subshell under various circumstances, such as when starting X). The shell forks, creates a "copy" of itself which shares the same text and data pages, but then execs a different program. At that point, I would expect that the data pages of that process become independent of the original shell's data pages (except perhaps if it's another shell), since the two programs have nothing to do with eachother. Is that correct? So then, does this new process share memory pages with an existing copy of the same program? Here, I would think it would share text pages, but not data pages, since the state of one is totally different from the state of the other... I would intuitively think that it wouldn't be worth the effort of mapping the old data pages to the new process, since in many cases they will need to be changed immediately. Really, I think there are 3 cases of the fork scenario you describe: - process forks a copy of itself - process forks a new program, which is not already running - process forks a new program, which IS already running I'd be curious what happens in each case. If you care to comment, please do! =8^) P.S. as partial answer to the original poster's question, I believe what Linux does to aid in the start-up of recently terminated programs is keep the disk blocks containing the program in buffer cache, so long as there is enough free memory to do that. -- We sometimes catch a window, a glimpse of what's beyond Was it just imagination stringing us along? --------------------------------------------------- Derek Martin | Unix/Linux geek ddm at pizzashack.org | GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |