Wu Fengguang <fengguang.wu@xxxxxxxxx> writes: > Linus reports a _really_ small & slow (505kB, 15kB/s) USB device, > on which blkid runs unpleasantly slow. He manages to optimize the blkid > reads down to 1kB+16kB, but still kernel read-ahead turns it into 48kB. > > lseek 0, read 1024 => readahead 4 pages (start of file) > lseek 1536, read 16384 => readahead 8 pages (page contiguous) > > The readahead heuristics involved here are reasonable ones in general. > So it's good to fix blkid with fadvise(RANDOM), as Linus already did. > > For the kernel part, Linus suggests: > So maybe we could be less aggressive about read-ahead when the size of > the device is small? Turning a 16kB read into a 64kB one is a big deal, > when it's about 15% of the whole device! > > This looks reasonable: smaller device tend to be slower (USB sticks as > well as micro/mobile/old hard disks). > > Given that the non-rotational attribute is not always reported, we can > take disk size as a max readahead size hint. This patch uses a formula > that generates the following concrete limits: > > disk size readahead size > (scale by 4) (scale by 2) > 1M 8k > 4M 16k > 16M 32k > 64M 64k > 256M 128k > --------------------------- (*) > 1G 256k > 4G 512k > 16G 1024k > 64G 2048k > 256G 4096k > > (*) Since the default readahead size is 128k, this limit only takes > effect for devices whose size is less than 256M. Scaling readahead by the size of the device may make sense up to a point. But really, that shouldn't be the only factor considered. Just because you have a big disk, it doesn't mean it's fast, and it sure doesn't mean that you should waste memory with readahead data that may not be used before it's evicted (whether due to readahead on data that isn't needed or thrashing of the page cache). So, I think reducing the readahead size for smaller devices is fine. I'm not a big fan of going the other way. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
