Theodore Tso wrote:
On Tue, Sep 23, 2008 at 08:18:54AM -0400, Ric Wheeler wrote:
I think that Alan is probably right - the magic number for modern drives
is probably closer to 256K. Having it be a /sys tunable (with a larger
default) would be a nice way to verify this.
I've played with this a bit, and with the "git status" workload,
increasing the magic number beyond 16 (64k) doesn't actually help,
because the number of inodes we need to touch wasn't big enough.
So I switched to a different workload, which ran "find /path -size 0
-print" with a much larger directory hierarchy. With that workload I
got the following results:
ra_bits ra_blocks ra_kb seconds % improvement
0 1 4 53.3 -
1 2 8 47.3 11.3%
2 4 16 41.7 21.8%
3 8 32 37.5 29.6%
4 16 64 34.4 35.5%
5 32 128 32 40.0%
6 64 256 30.7 42.4%
7 128 512 28.8 46.0%
8 256 1024 28.3 46.9%
9 512 2048 27.5 48.4%
Given these numbers, I'm using a default of inode_readahead_bits of 5
(i.3., 32 blocks, or 128k for 4k blocksize filesystems). For a
workload that is 100% stat-based, without any I/O, it is possible to
get better results by using a higher number, yes, but I'm concerned
that a larger readahead may end up interfering with other reads. We
need to run some other workloads to be sure a larger number won't
cause problems before we go more aggressive on this parameter.
I'll send the revised patch in another message.
- Ted
That sounds about right for modern S-ATA/SAS drives. I would expect that
having this be a tunable knob might help for some types of storage (SSD
might not care, but should be faster in any case?).
ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
