From: Christoph Hellwig <hch@lst.de>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Mike Snitzer <snitzer@kernel.org>,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/2] sd: also set max_user_sectors when setting max_sectors
Date: Fri, 24 May 2024 09:51:50 +0200 [thread overview]
Message-ID: <20240524075150.GA18024@lst.de> (raw)
In-Reply-To: <yq1o78wjrsw.fsf@ca-mkp.ca.oracle.com>
On Thu, May 23, 2024 at 02:53:40PM -0400, Martin K. Petersen wrote:
>
> Christoph,
>
> > sd can set a max_sectors value that is lower than the max_hw_sectors
> > limit based on the block limits VPD page. While this is rather
> > unusual,
>
> It's not particularly unusual. Virtually all arrays have a much smaller
> stripe or cache line size than what the average HBA can handle in one
> transfer. Using the device's preferred I/O size to configure max_sectors
> made a substantial difference performance-wise.
Well, in terms of Linux it is weird in that drivers weren't ever supposed
to set max_sectors directly but only provide max_hw_sectors (although
nbd also decreases it and rbd increases it in odd ways). Especially
as we already have an opt_in limit for the optimal size.
I'll find a way to sort it out and build a grand unified and somewhat
coherent theory out of it..
next prev parent reply other threads:[~2024-05-24 7:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 18:26 fix stacking of sd-imposed max_sectors Christoph Hellwig
2024-05-23 18:26 ` [PATCH 1/2] sd: also set max_user_sectors when setting max_sectors Christoph Hellwig
2024-05-23 18:53 ` Martin K. Petersen
2024-05-24 7:51 ` Christoph Hellwig [this message]
2024-05-23 18:26 ` [PATCH 2/2] block: stack max_user_sectors Christoph Hellwig
2024-05-23 18:54 ` Martin K. Petersen
2024-05-28 12:57 ` fix stacking of sd-imposed max_sectors Jens Axboe
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=20240524075150.GA18024@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=snitzer@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.