lkml.org 
[lkml]   [2001]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Locking comment on shrink_caches()

On Thu, 27 Sep 2001, Linus Torvalds wrote:

> prefetching and friends won't do _anything_ for the case of a cache
> line bouncing back and forth between CPU's.

yep. that is exactly what was happening with pagecache_lock, while an
8-way system served 300+ MB/sec worth of SPECweb99 HTTP content in 1500
byte packets. Under that kind of workload the pagecache is used
read-mostly, and due to zerocopy (and Linux's hyper-scalable networking
code) there isnt much left that pollutes caches and/or inhibits raw
performance in any way. pagecache_lock was the top non-conceptual
cacheline-miss offender in instruction-level profiles of such workloads.
Does it show up on a dual PIII with 128 MB RAM? Probably not as strongly.
Are there other offenders under other kinds of workloads that have a
bigger effect than pagecache_lock? Probably yes - but this does not
justify ignoring the effects of pagecache_lock.

(to be precise there was another offender - timerlist_lock, we've fixed it
before fixing pagecache_lock, and posted a patch for that one too. It's
available under http://redhat.com/~mingo/scalable-timers/. I know no other
scalability offenders for read-mostly pagecache & network-intensive
workloads for the time being.)

Ingo

-
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: 2005-03-22 13:03    [W:0.058 / U:0.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site