path: root/block/blk-sysfs.c
diff options
authorJens Axboe <>2016-12-12 16:43:26 -0800
committerLinus Torvalds <>2016-12-12 18:55:08 -0800
commit9491ae4aade6814afcfa67f4eb3e3342c2b39750 (patch)
treece3bd5d3a5c504548583ce581525011594589d59 /block/blk-sysfs.c
parentf1f5929cd9715c1cdfe07a890f12ac7d2c5304ec (diff)
mm: don't cap request size based on read-ahead setting
We ran into a funky issue, where someone doing 256K buffered reads saw 128K requests at the device level. Turns out it is read-ahead capping the request size, since we use 128K as the default setting. This doesn't make a lot of sense - if someone is issuing 256K reads, they should see 256K reads, regardless of the read-ahead setting, if the underlying device can support a 256K read in a single command. This patch introduces a bdi hint, io_pages. This is the soft max IO size for the lower level, I've hooked it up to the bdev settings here. Read-ahead is modified to issue the maximum of the user request size, and the read-ahead max size, but capped to the max request size on the device side. The latter is done to avoid reading ahead too much, if the application asks for a huge read. With this patch, the kernel behaves like the application expects. Link: Signed-off-by: Jens Axboe <> Acked-by: Johannes Weiner <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
Diffstat (limited to 'block/blk-sysfs.c')
1 files changed, 1 insertions, 0 deletions
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 9cc8d7c..ea374e8 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -212,6 +212,7 @@ queue_max_sectors_store(struct request_queue *q, const char *page, size_t count)
q->limits.max_sectors = max_sectors_kb << 1;
+ q->backing_dev_info.io_pages = max_sectors_kb >> (PAGE_SHIFT - 10);
return ret;