Re: btrfs: why default 4M readahead size?

[Chris Mason <chris.mason@xxxxxxxxxx>]

On Thu, Mar 18, 2010 at 09:42:57AM +0800, Shaohua Li wrote:
> Btrfs uses below equation to calculate ra_pages:
> 	fs_info->bdi.ra_pages = max(fs_info->bdi.ra_pages,
>               		4 * 1024 * 1024 / PAGE_CACHE_SIZE);
> is the max() a typo of min()? This makes the readahead size is 4M by default,
> which is too big.

Looks like things have changed since I tuned that number.  Fengguang has
been busy ;)

> I have a system with 16 CPU, 6G memory and 12 sata disks. I create a btrfs for
> each disk, so this isn't a raid setup. The test is fio, which has 12 tasks to
> access 12 files for each disk. The fio test is mmap sequential read. I measure
> the performance with different readahead size:
> ra size		io throughput
> 4M		268288 k/s
> 2M		367616 k/s
> 1M		431104 k/s
> 512K		474112 k/s
> 256K		512000 k/s
> 128K		538624 k/s
> The 4M default readahead size has poor performance.
> I also does sync sequential read test, the test difference in't that big. But
> the 4M case still has about 10% drop compared to the 512k case.

I'm surprised the 4M is so much slower.  At any rate, the larger size
was selected because btrfs checksumming means we need a bigger buffer to
keep the disks saturated.  Were you on a fancy intel box with hardware
crc32c enabled?

> 
> One might argue how about the case memory isn't tight. I tried only run a
> one-disk setup with only one task. The 4M ra almost has no difference with the
> 128K ra. I guess the 128k default ra size for backing dev is carefuly choosed
> to work with popular disks.
> So my question is why we have a default 4M readahead size even with noraid case?

I'm happy to tune it down if lower numbers are more appropriate now,
thanks for trying this!

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html