Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Mar 2009 17:31:13 +0100
From:      cpghost <cpghost@cordula.ws>
To:        Dan Nelson <dnelson@allantgroup.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Speeding up exit(2)?
Message-ID:  <20090315163113.GA1044@phenom.cordula.ws>
In-Reply-To: <20090315154849.GE24875@dan.emsphone.com>
References:  <20090315091301.GB1051@phenom.cordula.ws> <20090315154849.GE24875@dan.emsphone.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, Mar 15, 2009 at 10:48:49AM -0500, Dan Nelson wrote:
> In the last episode (Mar 15), cpghost said:
> > I've noticed that when a huge, partially or totally swapped out process
> > exits, there is a lot of disk activity going on, before the process truly
> > dies.  This is not necessarily due to sync(2), because it also happens
> > with CPU bound processes that write very little output.
> > 
> > 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)).
> 
> Are you sure this is actually in _exit, and not in a cleanup function
> executed by the application as it exits?  If there is a large linked list,
> for example, and the author has decided to actually free the list before
> exiting instead of just letting it disappear when the process exits, each
> swapped-out page will have to be brought back in as the list is traversed. 
> C++ programs may have destructors doing this behind the scenes.

Yes, that's quite possible. Meanwhile, I'm suspecting that free(3) is
the culprit, and not the vm subsystem itself; though I was not yet
able to construct a good example to be sure.

And you're quite right: cleaning up paged-out linked lists or other
dynamic data structures, either explicitly or via C++ destructors is
also an obvious reason for swap activity. Didn't think of it first.

> Best way to figure out what's going on is to attach to the program with gdb
> while it's swapping, and print a stack trace.

I'll try this. Very good idea.

> Also, since you mentioned a "totally swapped out" process exiting, are you
> terminating it externally with kill -9?  It may be writing a core dump,
> which will force the kernel to pull back swapped-out pages to write them to
> the core file.

Also an excellent point. I'm just killing them with Ctrl-C (SIGINT),
which won't result in a core dump. But a core dump would also reawaken
the pages, that's quite clear.

> 	Dan Nelson
> 	dnelson@allantgroup.com

Thanks for all the hints. The fog is slowly lifting. ;-)

-cpghost.

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



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20090315163113.GA1044>