[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1tur3vzkz.fsf@ca-mkp.ca.oracle.com>
Date: Tue, 26 Jan 2021 22:50:05 -0500
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Changheun Lee <nanich.lee@...sung.com>
Cc: martin.petersen@...cle.com, Damien.LeMoal@....com, arnd@...db.de,
hch@....de, jejb@...ux.ibm.com, jisoo2146.oh@...sung.com,
junho89.kim@...sung.com, linux-kernel@...r.kernel.org,
linux-scsi@...r.kernel.org, michael.christie@...cle.com,
mj0123.lee@...sung.com, oneukum@...e.com,
seunghwan.hyun@...sung.com, sookwan7.kim@...sung.com,
woosung2.lee@...sung.com, yt0928.kim@...sung.com
Subject: Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if
max_xfer_blocks is available
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
Powered by blists - more mailing lists