Date: Tue, 25 Oct 2005 15:45:42 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Marc Olzheim <marcolz@stack.nl> Cc: Daniel Eischen <deischen@freebsd.org>, arch@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: libc_r is deprecated Message-ID: <20051025153950.S31152@fledge.watson.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
On Tue, 25 Oct 2005, 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...) The change in performance from threading libraries varies for me a great deal by workload. I found that with MySQL, I did see significant improvements from switching to non-libc_r threading models, as the task was no longer blocked on synchronous I/O to disk. However, the results I posted in an earlier message illustrate a workload without synchronous blocking I/O, due to using sendfile() on a small set of files that basically live in the buffer cache. I've seen several workloads where using SMP improves performance, but in the test I posted earlier, SMP runs slower than UP, probably due to the fact that it's basically a test over overhead costs for context switch, system calls, and access to process data structures (such as file descriptors), so there's lots of room for overhead. I assume that the varying relative costs for libthr/libpthread/libc_r shed some light on things like the relative costs of system calls and context switches, as well as the degree to which the user and kernel schedulers can make effective use of available CPU resources. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051025153950.S31152>