From: Dan Helmick <dan.helmick@samsung.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>,
Luis Chamberlain <mcgrof@kernel.org>
Cc: "James Bottomley" <James.Bottomley@hansenpartnership.com>,
"Javier González" <javier.gonz@samsung.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Theodore Ts'o" <tytso@mit.edu>, "Hannes Reinecke" <hare@suse.de>,
"Keith Busch" <kbusch@kernel.org>,
"Pankaj Raghav" <p.raghav@samsung.com>,
"Daniel Gomez" <da.gomez@samsung.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: RE: [LSF/MM/BPF TOPIC] Cloud storage optimizations
Date: Fri, 10 Mar 2023 01:16:05 +0000 [thread overview]
Message-ID: <dfd0405cf7eb4b9ea8cccba97e31d25d@samsung.com> (raw)
In-Reply-To: <yq1ttytbox9.fsf@ca-mkp.ca.oracle.com>
> -----Original Message-----
> From: Martin K. Petersen [mailto:martin.petersen@oracle.com]
> Sent: Thursday, March 9, 2023 2:28 PM
> To: Luis Chamberlain <mcgrof@kernel.org>
> Cc: James Bottomley <James.Bottomley@hansenpartnership.com>; Dan
> Helmick <dan.helmick@samsung.com>; Martin K. Petersen
> <martin.petersen@oracle.com>; Javier González
> <javier.gonz@samsung.com>; Matthew Wilcox <willy@infradead.org>;
> Theodore Ts'o <tytso@mit.edu>; Hannes Reinecke <hare@suse.de>; Keith
> Busch <kbusch@kernel.org>; Pankaj Raghav <p.raghav@samsung.com>;
> Daniel Gomez <da.gomez@samsung.com>; lsf-pc@lists.linux-foundation.org;
> linux-fsdevel@vger.kernel.org; linux-mm@kvack.org; linux-
> block@vger.kernel.org
> Subject: Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations
>
>
> Luis,
>
> > A big future question is of course how / when to use these for
> > filesystems. Should there be, for instance a 'mkfs --optimal-bs' or
> > something which may look whatever hints the media uses ? Or do we just
> > leaves the magic incantations to the admins?
>
> mkfs already considers the reported queue limits (for the filesystems most
> people use, anyway).
>
> The problem is mainly that the devices don't report them. At least not very
> often in the NVMe space. For SCSI devices, reporting these parameters is
> quite common.
>
> --
> Martin K. Petersen Oracle Linux Engineering
Support for the NVMe Optimal Performance parameters is increasing in the vendor ecosystem. Customers are requiring this more and more from the vendors. For example, the OCP DC NVMe SSD spec has NVMe-AD-2 and NVMe-OPT-7 [1]. Momentum is continuing as Optimal Read parameters were recently added to NVMe too. More companies adding these parameters as a drive requirement to drive vendors would definitely help the momentum further.
I think there has been confusion among the vendors in the past on how to set various values for the best Host behavior. There are multiple (sometimes minor) inflection points in the performance of a drive. Sure. 4KB is too small to report by the drive, but shall we report our 16KB, 128KB, or some other inflection? How big of a value can we push this? We would always favor the bigger number.
There are benefits for both Host and Drive (HDD and SSD) to have larger IOs. Even if you have a drive reporting incorrect optimal parameters today, one can incubate the SW changes with larger IOs. If nothing else, you'll instantly save on the overheads of communicating the higher number of commands. Further doing an IO sized to be a multiple of the optimal parameters is also optimal. Enabling anything in the range 16KB - 64KB would likely be a great start.
[1] https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-0r21-pdf
Dan
next prev parent reply other threads:[~2023-03-10 1:16 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 3:52 Theodore Ts'o
2023-03-01 4:18 ` Gao Xiang
2023-03-01 4:40 ` Matthew Wilcox
2023-03-01 4:59 ` Gao Xiang
2023-03-01 4:35 ` Matthew Wilcox
2023-03-01 4:49 ` Gao Xiang
2023-03-01 5:01 ` Matthew Wilcox
2023-03-01 5:09 ` Gao Xiang
2023-03-01 5:19 ` Gao Xiang
2023-03-01 5:42 ` Matthew Wilcox
2023-03-01 5:51 ` Gao Xiang
2023-03-01 6:00 ` Gao Xiang
2023-03-02 3:13 ` Chaitanya Kulkarni
2023-03-02 3:50 ` Darrick J. Wong
2023-03-03 3:03 ` Martin K. Petersen
2023-03-02 20:30 ` Bart Van Assche
2023-03-03 3:05 ` Martin K. Petersen
2023-03-03 1:58 ` Keith Busch
2023-03-03 3:49 ` Matthew Wilcox
2023-03-03 11:32 ` Hannes Reinecke
2023-03-03 13:11 ` James Bottomley
2023-03-04 7:34 ` Matthew Wilcox
2023-03-04 13:41 ` James Bottomley
2023-03-04 16:39 ` Matthew Wilcox
2023-03-05 4:15 ` Luis Chamberlain
2023-03-05 5:02 ` Matthew Wilcox
2023-03-08 6:11 ` Luis Chamberlain
2023-03-08 7:59 ` Dave Chinner
2023-03-06 12:04 ` Hannes Reinecke
2023-03-06 3:50 ` James Bottomley
2023-03-04 19:04 ` Luis Chamberlain
2023-03-03 21:45 ` Luis Chamberlain
2023-03-03 22:07 ` Keith Busch
2023-03-03 22:14 ` Luis Chamberlain
2023-03-03 22:32 ` Keith Busch
2023-03-03 23:09 ` Luis Chamberlain
2023-03-16 15:29 ` Pankaj Raghav
2023-03-16 15:41 ` Pankaj Raghav
2023-03-03 23:51 ` Bart Van Assche
2023-03-04 11:08 ` Hannes Reinecke
2023-03-04 13:24 ` Javier González
2023-03-04 16:47 ` Matthew Wilcox
2023-03-04 17:17 ` Hannes Reinecke
2023-03-04 17:54 ` Matthew Wilcox
2023-03-04 18:53 ` Luis Chamberlain
2023-03-05 3:06 ` Damien Le Moal
2023-03-05 11:22 ` Hannes Reinecke
2023-03-06 8:23 ` Matthew Wilcox
2023-03-06 10:05 ` Hannes Reinecke
2023-03-06 16:12 ` Theodore Ts'o
2023-03-08 17:53 ` Matthew Wilcox
2023-03-08 18:13 ` James Bottomley
2023-03-09 8:04 ` Javier González
2023-03-09 13:11 ` James Bottomley
2023-03-09 14:05 ` Keith Busch
2023-03-09 15:23 ` Martin K. Petersen
2023-03-09 20:49 ` James Bottomley
2023-03-09 21:13 ` Luis Chamberlain
2023-03-09 21:28 ` Martin K. Petersen
2023-03-10 1:16 ` Dan Helmick [this message]
2023-03-10 7:59 ` Javier González
2023-03-08 19:35 ` Luis Chamberlain
2023-03-08 19:55 ` Bart Van Assche
2023-03-03 2:54 ` Martin K. Petersen
2023-03-03 3:29 ` Keith Busch
2023-03-03 4:20 ` Theodore Ts'o
2023-07-16 4:09 BELINDA Goodpaster kelly
2025-09-22 17:49 Belinda R Goodpaster
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=dfd0405cf7eb4b9ea8cccba97e31d25d@samsung.com \
--to=dan.helmick@samsung.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=da.gomez@samsung.com \
--cc=hare@suse.de \
--cc=javier.gonz@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=tytso@mit.edu \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox