Date: Sat, 5 Mar 2005 10:08:28 -0500 (EST) From: Daniel Eischen <deischen@freebsd.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: <Pine.GSO.4.43.0503051003090.13652-100000@sea.ntplx.net> In-Reply-To: <20050305101211.GA59471@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 5 Mar 2005, 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? There is room for improvement in the kernel upcall path. I got about a 7% improvement in some tests by caching upcall threads in the kernel rather than using a zone and always alocating them when needed. http://people.freebsd.org/~deischen/kse/sys.diffs I don't know whether the patches are totally correct. There is also room for improvement in libpthread. It was first designed for correctness, not speed. I'm working on some changes to improve mutex performance. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0503051003090.13652-100000>