linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Changheun Lee <nanich.lee@samsung.com>
To: martin.petersen@oracle.com
Cc: Damien.LeMoal@wdc.com, arnd@arndb.de, hch@lst.de,
	jejb@linux.ibm.com, jisoo2146.oh@samsung.com,
	junho89.kim@samsung.com, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org, michael.christie@oracle.com,
	mj0123.lee@samsung.com, nanich.lee@samsung.com, oneukum@suse.com,
	seunghwan.hyun@samsung.com, sookwan7.kim@samsung.com,
	woosung2.lee@samsung.com, yt0928.kim@samsung.com
Subject: Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available
Date: Wed, 27 Jan 2021 15:49:08 +0900	[thread overview]
Message-ID: <20210127064908.13571-1-nanich.lee@samsung.com> (raw)
In-Reply-To: <yq1tur3vzkz.fsf@ca-mkp.ca.oracle.com>

> Hello Changheun!
> 
> > I want to discuss using max_xfer_blocks instead of opt_xfer_blocks as
> > a optional.  For example, device reports opt_xfer_blocks is 512KB and
> > 1MB as a max_xfer_blocks too. Currently rw_max is set with 512KB only.
> 
> Because that's what the device asks for. If a device explicitly requests
> us to use 512 KB I/Os we should not be sending it 1 MB requests.
> 
> The spec is very clear. It says that if you send a command *larger* than
> opt_xfer_blocks, you should expect *slower* performance. That makes
> max_xfer_blocks a particularly poor choice for setting the default I/O
> size.
> 
> In addition to being slower, max_xfer_blocks could potentially also be
> much, much larger than opt_xfer_blocks. I understand your 512 KB vs. 1
> MB example. But if the max_xfer_blocks limit is reported as 1 GB, is
> that then the right value to use instead of 512 KB? Probably not.
> 
> If a device does not report an opt_xfer_blocks value that suits your
> workload, just override the resulting max_sectors_kb in sysfs. This is
> intentionally a soft limit so it can be adjusted by the user without
> having to change the kernel.
> 
> -- 
> Martin K. Petersen	Oracle Linux Engineering
> 

I understood what you said. I reviewed meaning of opt_xfer_blocks from
SCSI spec again. I think below is what you saw in spec.

The OPTIMAL TRANSFER LENGTH field indicates the optimal transfer size in
logical blocks for a single command shown in table 197. If a device server
receives one of these commands with a transfer size greater than this value,
then the device server may incur significant delays in processing the
command. If the OPTIMAL TRANSFER LENGTH field is set to zero, then there
is no reported optimal transfer size.

Thank you for kindly feedback. :)

---
Changheun Lee
Samsung Electronics

  parent reply	other threads:[~2021-01-27  7:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210113064521epcas1p32f0e65bc54d559b55db65bc5556103e8@epcas1p3.samsung.com>
2021-01-13 15:50 ` [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available Manjong Lee
     [not found]   ` <CGME20210120064450epcas1p1b00b7a040e0951a2da44abce916e1698@epcas1p1.samsung.com>
2021-01-20  8:00     ` Damien Le Moal
     [not found]       ` <CGME20210122072413epcas1p2d7bd97c9eae97b9b77d13e2c4a2f02f2@epcas1p2.samsung.com>
2021-01-22  7:08         ` Changheun Lee
2021-01-22  7:44           ` Damien Le Moal
2021-01-23  3:38             ` Martin K. Petersen
     [not found]               ` <CGME20210126041455epcas1p2c38ddc3bfe20bcf10217956b47096a33@epcas1p2.samsung.com>
2021-01-26  3:59                 ` Changheun Lee
2021-01-27  3:50                   ` Martin K. Petersen
     [not found]                     ` <CGME20210127070438epcas1p417a8c9288df420b0af1ed9d185c87a22@epcas1p4.samsung.com>
2021-01-27  6:49                       ` Changheun Lee [this message]
2021-01-20 15:49 ` Manjong Lee

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=20210127064908.13571-1-nanich.lee@samsung.com \
    --to=nanich.lee@samsung.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=arnd@arndb.de \
    --cc=hch@lst.de \
    --cc=jejb@linux.ibm.com \
    --cc=jisoo2146.oh@samsung.com \
    --cc=junho89.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=mj0123.lee@samsung.com \
    --cc=oneukum@suse.com \
    --cc=seunghwan.hyun@samsung.com \
    --cc=sookwan7.kim@samsung.com \
    --cc=woosung2.lee@samsung.com \
    --cc=yt0928.kim@samsung.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;
as well as URLs for NNTP newsgroup(s).