lkml.org 
[lkml]   [1998]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Thread implementations...

    On Sat, 20 Jun 1998, David S. Miller wrote:

    > With pthreads it achieves 811 req/s.
    > With user threads it achieves 1024.40 req/s.
    >
    > The machine is a single cpu ppro 200 with 128Mb of RAM running 2.1.104.
    >
    > If you have the opportunity, perform the same benchmark on an
    > architecture that implements context pids in the TLB. The entire TLB
    > is for all intents and purposes, flushed entirely of all userland
    > translations for even thread context switches.

    on x86 it is not flushed across thread-thread switches ... and on a PPro,
    parts of the TLB are tagged as 'global' (kernel pages obviously), which
    keeps the TLB-lossage even across non-shared-VM threads small. (zb->apache
    and apache->zb switches in this case).

    one thing i noticed about LinuxThreads, the most 'out of balance' basic
    pthreads operation in pthread_create(). Does NSPR create a pre-allocated
    pool of threads? (or some kind of adaptive pool?) If it's creating threads
    heavily (say per-request), then thats bad, at least with the current
    LinuxThreads implementation. We have a 1:5 gap between the latency of
    clone() and pthread_create() there...

    -- mingo


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.025 / U:0.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site