Messages in this thread | | | Date | Wed, 19 Aug 1998 19:52:32 +0200 (CEST) | From | MOLNAR Ingo <> | Subject | Re: 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
| |