Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Memory not freed?



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org