Date: Sat, 05 Mar 2005 08:21:47 -0700 From: Scott Long <scottl@samsco.org> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys proc.h umtx.h src/sys/kernkern_thread.c kern_umtx.c Message-ID: <4229CE8B.20703@samsco.org> In-Reply-To: <20050305101211.GA59471@FreeBSD.org> References: <200503050915.j259F30c058488@repoman.freebsd.org> <20050305101211.GA59471@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexey Dokuchaev wrote: > On Sat, Mar 05, 2005 at 09:15:03AM +0000, David Xu wrote: > >>davidxu 2005-03-05 09:15:03 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/sys proc.h umtx.h >> sys/kern kern_thread.c kern_umtx.c >> Log: >> Allocate umtx_q from heap instead of stack, this avoids >> page fault panic in kernel under heavy swapping. > > > So.. Slow malloc/free path at last. As a side note, could someone (not > necessarily David) comment on my impression that, for example, recently > reported not-so-optimal performance of our threading model(s) is largely due > to heavy use of malloc/free, as opposed to other operating systems out > there? Am I right thinking that this is main bottleneck? If malloc'ing is > so costly, why we're taking this path? Can kernel malloc() be optimized? > > Thanks. > > ./danfe All David's change does is allocate the umtx_q object at thread creation, it doesn't allocate it on every contested lock operation like was first suggested. So yes, it likely slows down thread creation by a small amount, but there is already a lot of other overhead there. Thread allocation is already optimized by UMA, and it might be possible to optmize the sub-allocations by putting them under UMA too. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4229CE8B.20703>