Speeding up exit(2)?

cpghost cpghost at cordula.ws
Sun Mar 15 09:42:21 PDT 2009

On Mon, Mar 16, 2009 at 03:24:51AM +1100, Ian Smith wrote:
> On Sun, 15 Mar 2009 11:01:41 +0100 cpghost <cpghost at cordula.ws> wrote:
>  > On Sun, Mar 15, 2009 at 10:27:53AM +0100, Wojciech Puchar wrote:
>  > > > Not sure what's really going on there, but apparently, the process
>  > > > reads in pages from swap that have been paged out previously
>  > > > (according to top(1)).
>  > > 
>  > > is it your program and you are sure it's on exit?
>  > 
>  > Every memory hungry program is concerned; and yes: it happens exactly
>  > on exit.
>  > 
>  > > it's because the program is writted the way it's doing a lot of things 
>  > > (probably unneeded) on exit.
>  > 
>  > Have a look at what happens during exit:
>  >   /usr/src/sys/kern/kern_exit.c:exit1()
>  > 
>  > especially at the call to vm_waitproc():
>  >   /usr/src/sys/vm/vm_glue.c:vm_waitproc
>  > 
>  > which calls vmspace_exitfree():
>  >   /usr/src/sys/vm/vm_map.c:vmspace_exitfree()
>  > 
>  > Now, vmspace_exit() and vmspace_exitfree() ultimately call:
>  >   /usr/src/sys/vm/vm_map.c:vmspace_dofree()
>  > 
>  > It then goes deep into the bowels of vm amd pmap,
>  > and that's the place where the pages are paged in
>  > again (I think).
> Sounds right.  This is easy to demonstrate on a laptop with 160MB RAM, 
> running a bunch of servers + X + KDE, then running Mozilla, then opening 
> about 30 tabs of pages, many of which run vast and buggy javascript ..
> By this stage mozilla is about 150MB with about 60MB resident, and swap 
> is pushing 200MB.  *seriously* paging, just on flipping to another tab.  
> Now close mozilla and watch top while it's shutting down.  Go and pour 
> yourself a cuppa, there's no hurry ..
> Apart from having to close each tab/window, freeing all its resources, 
> bits of the executable itself need to be paged in to do various things, 
> which may need to page out some more.  What's amazing is that it can do 
> that for several minutes, coming out unscathed when it finally quits!

Yes, that's exactly what I'm seeing.

And of course, after firefox finally shuts down, everything else is
also (mostly) paged out, including most of X, so it takes some time to
get a fully responsive system again.

It's amazing how closing a process can actually make the system even
less responsive.

But as Dan has pointed out, firefox et al. are probably written in
such a way that they reawaken all their dynamic data structures
from swap while cleaning up. There's not much one can do from the
OS side to prevent this from happening.

> (extreme example, but a true story from a wild ebay session yesterday :)
>  > > not exit(2) itself
> Well that just starts that big VM ball rolling, so to speak .. so it's a 
> tad more complex than a program that fills memory (+ swap) then exits.

Yup, that's obviously more complicated: C++ dtors, atexit() handlers, etc.
are called at this point. VM itself seems fast enough to clean up the
vm space of any process without much swap I/O (but I'm not 100% sure yet).

> cheers, Ian


Cordula's Web. http://www.cordula.ws/

More information about the freebsd-questions mailing list