[PATCH 02/12] block: take io_opt and io_min into account for max_sectors
Christoph Hellwig
hch at lst.de
Thu May 30 22:54:56 PDT 2024
On Thu, May 30, 2024 at 09:48:06PM +0200, Ilya Dryomov wrote:
> For rbd, this change effectively lowers max_sectors from 4M to 64K or
> less and that is definitely not desirable. From previous interactions
> with users we want max_sectors to match max_hw_sectors -- this has come
> up a quite a few times over the years. Some people just aren't aware
> of the soft cap and the fact that it's adjustable and get frustrated
> over the time poured into debugging their iostat numbers for workloads
> that can send object (set) size I/Os.
>
> Looking at the git history, we lowered io_opt from objset_bytes to
> opts->alloc_size in commit [1], but I guess io_opt was lowered just
> along for the ride. What that commit was concerned with is really
> discard_granularity and to a smaller extent io_min.
>
> How much difference does io_opt make in the real world? If what rbd
> does stands in the way of a tree-wide cleanup, I would much rather bump
> io_opt back to objset_bytes (i.e. what max_user_sectors is currently
> set to).
The only existing in-kernel usage is to set the readahead size.
Based on your comments I seems like we should revert io_opt to
objset to ->alloc_size in a prep patch?
More information about the linux-um
mailing list