libc_r is deprecated
Robert Watson
rwatson at FreeBSD.org
Tue Oct 25 07:45:43 PDT 2005
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
More information about the freebsd-arch
mailing list