Re: libc_r is deprecated

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 10/25/05

  • Next message: David Xu: "Re: libc_r is deprecated" 
    Date: Tue, 25 Oct 2005 15:45:42 +0100 (BST)
To: Marc Olzheim <marcolz@stack.nl>

    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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: David Xu: "Re: libc_r is deprecated"