lkml.org 
[lkml]   [2006]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Can context switches be faster?
    From
    Date
    On Thu, 2006-10-12 at 14:56 -0400, John Richard Moser wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    >
    >
    > Arjan van de Ven wrote:
    > > On Thu, 2006-10-12 at 14:25 -0400, John Richard Moser wrote:
    > >
    > > Hi,
    > >
    > >> So apparently most CPUs virtually address L1 cache and physically
    > >> address L2; but sometimes physically addressing L1 is better.. hur.
    > >
    > > if you are interested in this I would strongly urge you to read Curt
    > > Schimmel's book (UNIX(R) Systems for Modern Architectures: Symmetric
    > > Multiprocessing and Caching for Kernel Programmers); it explains this
    > > and related materials really really well.
    > >
    >
    > That will likely be more useful when I've got more background knowledge;

    the book is quite explenatory, so maybe your uni has it in the library
    so that you can try to see if it makes sense?

    > >
    > > the cache flushing is a per architecture property. On x86, the cache
    > > flushing isn't needed; but a TLB flush is. Depending on your hardware
    > > that can be expensive as well.
    > >
    >
    > Mm. TLB flush is expensive, and pretty unavoidable unless you do stupid
    > things like map libc into the same address everywhere.

    TLB flush is needed if ANY part of the address space is pointing at
    different pages. Since that is always the case for different processes,
    where exactly glibc is doesn't matter... as long as there is ONE page of
    memory different you have to flush. (And the flush is not expensive
    enough to do partial ones based on lots of smarts; the smarts will be
    more expensive than just doing a full flush)

    > TLB flush
    > between threads in the same process is probably avoidable; aren't
    > threads basically processes with the same PID in something called a
    > thread group? (Hmm... creative scheduling possibilities...)

    the scheduler is smart enough to avoid the flush then afaik
    (threads share the "mm" in Linux, and "different mm" is used as trigger
    for the flush. Linux is even smarter; kernel threads don't have any mm
    at all so those count as wildcards in this respect, so that if you have
    "thread A" -> "kernel thread" -> "thread B" you'll have no flush)



    -
    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: 2006-10-12 21:05    [W:0.023 / U:0.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site