lkml.org 
[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PFC]: hash instrumentation
Hi,

On Fri, 9 Apr 1999 21:37:57 +0200 (CEST), Andrea Arcangeli
<andrea@e-mind.com> said:

> I am also a bit worried by shrink_dcache_memory(). It looks like to me
> that it's recalled too late. You should swapout heavily or delete files in
> order to shrink the dcache right now. And the shrink in my tree is more
> finegrined than the complete shrink done by the stock kernel, and since my
> tree is very stable (no peak of low memory) also during swap I think that
> shrink_dcache memory is __never__ recalled with normal operations that
> also involve swap. So I think I'll move shrink_dcache_memory() _before_
> swap_out() to see if it's been part of the bottleneck.

Good for testing, but terrible for high-memory machines which rely on
dcache to maintain performance.

As an interesting data point, I applied Chuck's last pair of buffer and
page cache hash updates (the new buffer hash function, and the larger
PAGE_HASH_BITS) to a 2.2.5 kernel to measure the impact on a parallel
build of the current glibc-2.1 rpms on a 4-way Xeon. Each of those two
improvements gained about 30 seconds of wall-clock time on a complete
build, taking it down from 15 minutes to 14.

Adding 4 extra bits to the dcache hash was worth 2 full minutes; 12
minutes total build time.

This was absolutely obvious from the readprofile(8) traces, where
d_lookup() was massively dominating the system CPU time (I had made both
the page and buffer hash lookup functions into externs at this point so
that they would all be profiled separately, not as inlines). d_lookup
was using about 4 times as much CPU as the nearest other functions
(which iirc were the page fault COW handler and file read() actors, both
of which perform large copies).

Shrinking the dcaches excessively in this case will simply masaccre the
performance. Apparently glibc-2.1 is a particularly heavy test of
stat() performance, but then many other common server workloads are too.
Interestingly, when performing a full kernel build on the same box, the
d_lookup() cost is so low that it is hardly even on the map.

Cheers,
Stephen

-
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.tux.org/lkml/

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