Date: Mon, 30 Nov 2015 15:01:21 +1100 From: Kubilay Kocak <koobs@FreeBSD.org> To: Kirk McKusick <mckusick@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r291460 - head/sys/kern Message-ID: <565BCA11.4090600@FreeBSD.org> In-Reply-To: <201511292142.tATLgQW0042923@repo.freebsd.org> References: <201511292142.tATLgQW0042923@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30/11/2015 8:42 AM, Kirk McKusick wrote: > Author: mckusick > Date: Sun Nov 29 21:42:26 2015 > New Revision: 291460 > URL: https://svnweb.freebsd.org/changeset/base/291460 > > Log: > As the kernel allocates and frees vnodes, it fully initializes them > on every allocation and fully releases them on every free. These > are not trivial costs: it starts by zeroing a large structure then > initializes a mutex, a lock manager lock, an rw lock, four lists, > and six pointers. And looking at vfs.vnodes_created, these operations > are being done millions of times an hour on a busy machine. > > As a performance optimization, this code update uses the uma_init > and uma_fini routines to do these initializations and cleanups only > as the vnodes enter and leave the vnode_zone. With this change the > initializations are only done kern.maxvnodes times at system startup > and then only rarely again. The frees are done only if the vnode_zone > shrinks which never happens in practice. For those curious about the > avoided work, look at the vnode_init() and vnode_fini() functions in > kern/vfs_subr.c to see the code that has been removed from the main > vnode allocation/free path. > > Reviewed by: kib > Tested by: Peter Holm > > Modified: > head/sys/kern/vfs_subr.c > Kirk, Very interesting. Any estimation / expectation on the performance impact^W benefit of this, and in what scenario's / use-cases it might be particularly beneficial? Any benchmarks or tests you can share? ./koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?565BCA11.4090600>