Date: Wed, 26 Oct 2005 07:18:33 +0800 From: David Xu <davidxu@freebsd.org> To: Marc Olzheim <marcolz@stack.nl> Cc: Daniel Eischen <deischen@freebsd.org>, arch@freebsd.org, Robert Watson <rwatson@FreeBSD.org> Subject: Re: libc_r is deprecated Message-ID: <435EBD49.7090207@freebsd.org> In-Reply-To: <20051025134834.GB62148@stack.nl> References: <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net> <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org> <20051025134834.GB62148@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Olzheim wrote: >>libc_r runs on single kernel thread, so if you are continue using libc_r, >>you are not testing TCP/IP with multithreads program, this may give you >>false data. Only kernel threads based server can test to see if the TCP/IP >>stack locking works well. >> >> > >Erhm, its not about testing the TCP/IP stack locking, this is about >stable and raw performance. Of course the single kernel thread might >have a negative impact on total performance, but in our real world >applications, I don't see a real performance boost from KSE. > >What I do see is easier and cleaner programming with KSE, but once >you've done all the work to get usable libc_r based I/O, it works good. >(Well, unless you need to fork+exec from a heavily mallocing thread >system, without a patch similar to the one in PR threads/76690...) > >Marc > > What is raw performance? are you comparing it with RELENG-4, if you only need a single thread, why should we start SMP project ? I am interesting to see libthr is worse than libc_r in real world application, give us example. I have an example, run Dave's crew example from his book, libc_r just falls on its face. http://people.freebsd.org/~davidxu/ptest.tgz also, Robert can get better result if he does not use libc_r but use a state machine but not thread to serve http request like an example in ACE. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?435EBD49.7090207>