Re: [PATCH] mm: don't cap request size based on read-ahead setting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/20/2016 09:44 PM, Hillf Danton wrote:
On Saturday, November 19, 2016 3:41 AM Jens Axboe wrote:
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.

Is it also making any sense to see 4M reads to meet 4M requests if
the underlying device can support 4M IO?

Depends on the device, but yes. Big raid set? You definitely want larger
requests. Which is why we have the distinction between max hardware and
kernel IO size.

By default we limit the soft IO size to 1280k for a block device. See
also:

commit d2be537c3ba3568acd79cd178327b842e60d035e
Author: Jeff Moyer <jmoyer@xxxxxxxxxx>
Date:   Thu Aug 13 14:57:57 2015 -0400

    block: bump BLK_DEF_MAX_SECTORS to 2560

--
Jens Axboe

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]