Subject: Re: Speeding up fork/wait path
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Chuck Silvers <email@example.com>
Date: 11/02/2003 12:09:02
On Sun, Nov 02, 2003 at 08:06:10PM +0100, Jaromir Dolecek wrote:
> I implemented similar solution.
> Exiting process now:
> 1. pmap_deactivate()s the address space and frees the vmspace
> 2. runs cpu_wait() (tears down TSS on i386 & amd64)
> 3. makes the process SZOMB
> 4. keeps KERNEL_PROC_LOCK()
this definitely looks like the right direction.
however, instead of this part:
> There is new uvm_uarea_collect(), which is called from strategic
> places. This routine frees any u-areas over the limit, and
> obviously can block. ATM this routine is called from pagedaemon thread,
> from sys_wait4(), and in during process exit if the process had
> any (>1) lwps before the exit.
how about we extend the pool code to handle objects larger than a page?
then all the existing infrastructure to deal with lazily freeing memory
back to the system will take care of all this.
I also want to use the larger-than-a-page pool stuff to allocate exec arg
buffers (with a new option to allocate ZFOD instead of wired memory).
freeing these buffers is a significant cost of execve() on eg. sparc
due to the cache flushing, so letting the pool code cache them would