cvs commit: src/sys/sys proc.h umtx.h src/sys/kernkern_thread.c kern_umtx.c

[Daniel Eischen]

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