From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Long Li <longli@microsoft.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Tom Yan <tom.ty89@gmail.com>,
"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
"linux-scsi\@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sd: remove redundant check for BLK_DEF_MAX_SECTORS
Date: Wed, 08 Jun 2016 23:29:33 -0400 [thread overview]
Message-ID: <yq1fusnjazm.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <SN1PR0301MB1983F2C779D54D1D4C57086BCE5E0@SN1PR0301MB1983.namprd03.prod.outlook.com> (Long Li's message of "Wed, 8 Jun 2016 04:22:21 +0000")
>>>>> "Long" == Long Li <longli@microsoft.com> writes:
Long,
Long> The problem I'm trying to solve is that, I want to have lower
Long> layer driver to setup max_sectors bigger than
Long> BLK_DEF_MAX_SECTORS.
Capping at BLK_DEF_MAX_SECTORS unless a device has explicitly reported
requirements is intentional. We have not had good experiences with
making I/O requests too big in general. So BLK_DEF_MAX_SECTORS has
deliberately been kept small. However, it was recently bumped to 1MB and
change by default.
Long> n Hyper-v, we use 2MB max transfer I/O size, in future version the
Long> max transfer I/O size will increase to 8MB.
But presumably you provide a BLOCK LIMITS VPD for your virtual targets?
Long> The reason why I think it may not be necessary for sd.c to setup
Long> max_sectors, it's because this value may have already been setup
Long> twice before reaching the code in sd.c: 1. When this disk device
Long> is first scanned, or re-scanned (in scsi_scan.c), where it
Long> eventually calls __scsi_init_queue(), and use the max_sectors in
Long> the scsi_host_template. 2. in slave_configure of
Long> scsi_host_template, when the lower layer driver implements this
Long> function in its template and it can change this value there.
Those cause limits to be set for the controller. We won't know the
device limits until we hit revalidate.
blk_queue_max_hw_sectors() will also clamp the R/W max at
BLK_DEF_MAX_SECTORS, though.
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2016-06-09 3:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-04 3:57 Long Li
2016-06-04 8:41 ` Tom Yan
2016-06-04 15:18 ` Long Li
2016-06-05 5:16 ` Tom Yan
2016-06-07 3:42 ` Martin K. Petersen
2016-06-08 4:22 ` Long Li
2016-06-09 3:29 ` Martin K. Petersen [this message]
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=yq1fusnjazm.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=tom.ty89@gmail.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
Powered by JetHome