* Oddities in brd queue limits
@ 2024-04-02 13:17 Hannes Reinecke
2024-04-02 13:18 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Hannes Reinecke @ 2024-04-02 13:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-block@vger.kernel.org
Hi Christoph,
brd ends up with the following queue limits:
optimal_io_size: 0
minimum_io_size: 4096
hw_sector_size: 512
physical_block_size: 4096
which I find particularly odd; how can the minimum I/O size be _larger_
than the hw_sector_size? Wouldn't that imply that we can only send I/O
in units of physical block size, rendering the hw_sector_size pretty
much pointless?
Or what is the idea here?
Btw, I would have expected brd to set 'optimal_io_size' to 4k, and
minimum_io_size to 512 bytes. Which would've been an alternative fix.
Cheers,
Hannes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Oddities in brd queue limits
2024-04-02 13:17 Oddities in brd queue limits Hannes Reinecke
@ 2024-04-02 13:18 ` Christoph Hellwig
2024-04-02 13:21 ` Hannes Reinecke
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2024-04-02 13:18 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Christoph Hellwig, linux-block@vger.kernel.org
On Tue, Apr 02, 2024 at 03:17:26PM +0200, Hannes Reinecke wrote:
> Hi Christoph,
>
> brd ends up with the following queue limits:
>
> optimal_io_size: 0
> minimum_io_size: 4096
> hw_sector_size: 512
> physical_block_size: 4096
>
> which I find particularly odd; how can the minimum I/O size be _larger_
> than the hw_sector_size? Wouldn't that imply that we can only send I/O
> in units of physical block size, rendering the hw_sector_size pretty much
> pointless?
The minimum_io_size is always larger or equal to hw sector size.
It really is the minimal efficient I/O size.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Oddities in brd queue limits
2024-04-02 13:18 ` Christoph Hellwig
@ 2024-04-02 13:21 ` Hannes Reinecke
2024-04-02 13:41 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Hannes Reinecke @ 2024-04-02 13:21 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-block@vger.kernel.org
On 4/2/24 15:18, Christoph Hellwig wrote:
> On Tue, Apr 02, 2024 at 03:17:26PM +0200, Hannes Reinecke wrote:
>> Hi Christoph,
>>
>> brd ends up with the following queue limits:
>>
>> optimal_io_size: 0
>> minimum_io_size: 4096
>> hw_sector_size: 512
>> physical_block_size: 4096
>>
>> which I find particularly odd; how can the minimum I/O size be _larger_
>> than the hw_sector_size? Wouldn't that imply that we can only send I/O
>> in units of physical block size, rendering the hw_sector_size pretty much
>> pointless?
>
> The minimum_io_size is always larger or equal to hw sector size.
> It really is the minimal efficient I/O size.
>
So is it a hard limit (as in: we cannot send I/O smaller than that)
or a soft limit (as in: we should not send I/O smaller than that)?
Cheers,
Hannes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Oddities in brd queue limits
2024-04-02 13:21 ` Hannes Reinecke
@ 2024-04-02 13:41 ` Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2024-04-02 13:41 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Christoph Hellwig, linux-block@vger.kernel.org
On Tue, Apr 02, 2024 at 03:21:00PM +0200, Hannes Reinecke wrote:
> So is it a hard limit (as in: we cannot send I/O smaller than that)
> or a soft limit (as in: we should not send I/O smaller than that)?
It is a completely soft hint that isn't used by anything in the
kernel I/O path.
(as a quick grep would tell..)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-04-02 13:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-02 13:17 Oddities in brd queue limits Hannes Reinecke
2024-04-02 13:18 ` Christoph Hellwig
2024-04-02 13:21 ` Hannes Reinecke
2024-04-02 13:41 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).