From: Damien Le Moal <dlemoal@kernel.org>
To: John Garry <john.g.garry@oracle.com>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP
Date: Wed, 18 Jun 2025 18:47:13 +0900 [thread overview]
Message-ID: <99834ce9-a581-4998-bd23-d66d20f990fa@kernel.org> (raw)
In-Reply-To: <acc347c6-5b75-40e0-b9c0-ba70819bdcd9@oracle.com>
On 6/18/25 18:06, John Garry wrote:
> On 18/06/2025 07:00, Damien Le Moal wrote:
>> Back in 2015, commit d2be537c3ba3 ("block: bump BLK_DEF_MAX_SECTORS to
>> 2560") increased the default maximum size of a block device I/O to 2560
>> sectors (1280 KiB) to "accommodate a 10-data-disk stripe write with
>> chunk size 128k". This choice is rather arbitrary and since then,
>> improvements to the block layer have software RAID drivers correctly
>> advertize their stripe width through chunk_sectors and abuses of
>> BLK_DEF_MAX_SECTORS_CAP by drivers (to set the HW limit rather than the
>> default user controlled maximum I/O size) have been fixed.
>>
>> Since many block devices can benefit from a larger value of
>> BLK_DEF_MAX_SECTORS_CAP, and in particular HDDs, increase this value to
>> be 4MiB, or 8192 sectors.
>>
>> And given that BLK_DEF_MAX_SECTORS_CAP is only used in the block layer
>> and should not be used by drivers directly, move this macro definition
>> to the block layer internal header file block/blk.h.
>>
>> Suggested-by: Martin K . Petersen <martin.petersen@oracle.com>
>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
>
> Regardless of comment below:
> Reviewed-by: John Garry <john.g.garry@oracle.com>
>
>> ---
>> Changes from v1:
>> - Move BLK_DEF_MAX_SECTORS_CAP definition to block/blk.h
>
> it's only referenced in blk-settings.c, so I don't know why it doesn't
> live there.
>
> However it is co-located with enum blk_default_limits and the same
> comment goes for members of enum blk_default_limits. I think all those
> in enum blk_default_limits could potentially be moved to blk-settings.c
> after Christoph's work for atomic queue limit updates.
I actually checked that and a few drivers are still using 2 of the 4 enum defaults.
Jens,
DO you prefer we move BLK_DEF_MAX_SECTORS_CAP to blk-settings.c ? blk.h has a
couple of settings macro at the top, it is together with that for now.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2025-06-18 9:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 6:00 [PATCH v2] block: Increase BLK_DEF_MAX_SECTORS_CAP Damien Le Moal
2025-06-18 6:17 ` Hannes Reinecke
2025-06-18 8:51 ` Johannes Thumshirn
2025-06-18 9:06 ` John Garry
2025-06-18 9:47 ` Damien Le Moal [this message]
2025-06-18 10:19 ` Martin K. Petersen
2025-06-23 13:40 ` Christoph Hellwig
2025-06-24 16:49 ` Jens Axboe
2025-08-27 7:07 ` Sebastian Andrzej Siewior
2025-08-27 7:38 ` Christoph Hellwig
2025-08-27 7:52 ` Sebastian Andrzej Siewior
2025-08-27 8:00 ` Christoph Hellwig
2025-08-27 8:03 ` Damien Le Moal
2025-08-27 8:01 ` Damien Le Moal
2025-08-27 8:42 ` Sebastian Andrzej Siewior
2025-08-27 9:01 ` Damien Le Moal
2025-08-27 10:16 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99834ce9-a581-4998-bd23-d66d20f990fa@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox