Subject: Re: root file system type: ffs 
---------
[ Please redirect all followups to tech-kern ONLY! --thorpej ]

On Mon, 31 Aug 98 21:08:49 CDT 
 Chuck Cranor <chuck@maria.wustl.edu> wrote:

 > i believe the pool allocator has uncovered a design problem in the
 > process exit code path.

I believe I have fixed the problem.  I have tested it on Alpha and x86,
but not the other platforms yet.  Charles Hannum suggested the reaper
thread.

Basically this does the following:

	- Creates a new kernel thread, the "reaper".  Reaper sleeps on
	  the (new) deadproc list.

	- In exit1(), processes are not put on zombproc.  They are only
	  removed from allproc.

	- cpu_exit() no longer frees the vmspace and stack of the dead
	  process.  Instead, once it is safe to do so (i.e. we're no
	  longer running on the dead process's stack, etc.), cpu_exit()
	  calls exit2() to schedule the freeing of the vmspace and stack.

	- exit2() places the proc on the deadproc list, and wakes up the
	  reaper.

	- Reaper runs, freeing the vmspace and stack of all processes
	  on the deadproc list.  Once the vmspace and stack are freed,
	  the process is put on the zombproc list, and the parent
	  notified that the dead process has exited.

Eventually, we can have a reaper thread bound to each CPU in the system.
Something like this really is going to be necessary in the multiprocessor
environment, because e.g. someone else might be holding the lock on the
vm_map, requiring a sleep, etc.

The diffs can be found at:

	ftp://ftp.netbsd.org/pub/incoming/thorpej/reaper.diff

If I hear no objections, I'll commit them tomorrow afternoon/evening.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 940 5942