lkml.org 
[lkml]   [2002]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] Native POSIX Thread Library 0.1

    On Fri, 20 Sep 2002, Bill Huey wrote:

    > You might like to try a context switching/thread wakeup performance
    > measurement against FreeBSD's libc_r. I'd imagine that it's difficult to
    > beat a system like that since they keep all of that stuff in userspace
    > since it's just 2 context switches and a call to their thread-kernel.

    our kernel thread context switch latency is below 1 usec on a typical P4
    box, so our NPT library should compare pretty favorably even in such
    benchmarks. We get from the pthread_create() call to the first user
    instruction of the specified thread-function code in less than 2 usecs,
    and we get from pthread_exit() to the thread that does the pthread_join()
    in less than 2 usecs as well - all of these operations are done via a
    single system-call and a single context switch.

    also consider the fact that the true cost of M:N threading does not show
    up with just one or two threads running. The true cost comes when
    thousands of threads are running, each of them doing nontrivial work that
    matters, ie. IO. The true cost of M:N shows up when threading is actually
    used for what it's intended to be used :-) And basically nothing offloads
    work to threads for them to just do userspace synchronization - real,
    useful work always involves some sort of IO and kernel calls. At which
    point M:N loses out badly.

    M:N's big mistake is that it concentrates on what matters the least:
    user<->user context switches. Nothing really wants to do that. And if it
    does, it's contended on some userspace locking object, at which point it
    doesnt really matter whether the cost of switching is 1 usec or 0.5 usecs,
    the main application cost is the lost paralellism and increased cache
    trashing due to the serialization - independently of what kind of
    threading abstraction is used.

    and since our NPT library uses futexes for *all* userspace synchronization
    primitives (including internal glibc locks), all uncontended
    synchronization is done purely in user-space. [and for the contended case
    we *want* to switch into the kernel.]

    Ingo

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:29    [W:4.141 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site