lkml.org 
[lkml]   [1998]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Notebooks

    On Wed, 19 Aug 1998, Andi Kleen wrote:

    > On a P90 the localhost TCP numbers increased from 11MB/s to 11.55MB/s

    On the Pentium, data cache is 8K, 2-way set associative. In practice
    conflicting cachelines happen very often. Typically if you copy 1 skb into
    another one (this happens very often, at least once for every skb), and if
    you use bigger buffer sizes, it's easy to see that if these two buffers
    have the same cache alignment (bad color), they will sweep say the local
    stack out of the L1 cache, and some global variables.

    > (and they got more stable, with 10 tests without cache colouring the numbers
    > varied a lot, while with it they were nearly constant - this shows that it has
    > a effect)

    conflicting cachelines is a random effect. With a 2-ways associative cache
    it has a high probability if combined with 1k+ memory copies, but it's
    still random. Say for bw_tcp localhost, with default MTU ~4k, there is a
    50% probability that we sweep half of the L1 cache with transferring 1 MTU
    data from user space to target user space! Especially with a benchmark,
    where we have say 2x 64k ping-pong buffers, it's easy to see that a X% of
    the transferred data will sweep the L1 cache. So in the localhost example,
    for every packet we sweep about 25% of the L1 cache. (ok, the example is
    exagerated, but you get the point) And the L1 cache's LRU scheme does not
    help since loading (the useless) skb into the L1 cache is mandatory. On
    the P5, the target write does not cause a new cacheline (guess why ;) to
    be created, but with a benchmark it will get into the L1 cache in the next
    phase. So benchmarks are big 'cache flushers' for simple L1 caches.

    (i think on a typical socket 7 board, a cacheline flush causes DMA
    busmaster snoops to block until the flush is finished, but i'm not sure
    about this one)

    i would not be surprised if this effect is not nearly as noticable on a P6
    class CPU. There a 'one-time' cacheline has much more time and higher
    chance to be 'voluntarely' flushed out of cache due to lack of usage.
    Also, on P6 class CPUs the microcode usually knows about these issues and
    i bet for bigger string operations it marks cachelines as 'less likely to
    be used soon'.

    -- mingo



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

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