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:0.243 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site