From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Changho Choi-SSI <changho.c@ssi.samsung.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] multi-stream IO hint implementation proposal for LSF/MM 2016
Date: Wed, 17 Feb 2016 16:46:16 -0800 [thread overview]
Message-ID: <20160218004616.GA97837@jaegeuk.gateway> (raw)
In-Reply-To: <20160217152155.GA14140@quack.suse.cz>
> > Linux Kernel Multi-stream I/O Hint Implementation
> >
> > Enterprise, datacenter, and client systems increasingly deploy NAND
> > flash-based SSDs. However, in use, SSDs cannot avoid inevitable garbage
> > collection that deterministically causes write amplification which
> > decreases device performance. Unfortunately, write amplification also
> > decreases SSD lifetime. However, with multi-stream, unavoidable garbage
> > collection overhead (e.g., write amplification) can be significantly
> > reduced. For multi-stream devices, the host tags device I/O write
> > requests with a stream ID (e.g., I/O hint). The SSD controller places the
> > data in media erase blocks according to the stream ID. For example, a SSD
> > controller stores data with same stream ID in an associated physical
> > location inside SSD. In this way, the multi-stream depends on host I/O
> > hints. So it is useful to develop how to implement multi-stream I/O hints
> > under limited protocol constraints. The T10 SCSI standard group has
> > already standardized the multi-stream feature and NVMe standardization is
> > an ticipated in March, 2016. Many Linux users want to leverage
> > multi-stream as a mainstream Linux feature since they have seen
> > performance improvement and SSD lifetime extension when evaluating
> > multi-stream enabled devices. Hence, the multi-stream feature is a good
> > Linux community development candidate and should be discussed within the
> > community. I propose this multi-stream topic (i.e., I/O write hint
> > implementation) in a discussion session. I can briefly present the
> > multi-stream system architecture and answer any technical questions.
>
> So a key question for a feature like this is: How many stream IDs are
> devices going to support? Because AFAIR so far the answer was "it depends
> on the device". However the design how stream IDs can be used greatly
> differs between "a couple of stream IDs" and e.g. 2^32 stream IDs. Without
> this information I don't think the discussion would be very useful. So can
> you provide some rough numbers?
I can think of an RFC which proposed context IDs for eMMCs long time ago [1].
One of my concerns is, if filesystem gives any hints through bios, block layer
loses a chance to merge consecutive bios due to the different ids, which results
in performance jitters.
IMO, if there's something new, it'd be worth to see how to open, close, and
assign IDs as well as any practical numbers representing there-in trade-offs.
[1] http://comments.gmane.org/gmane.linux.kernel.mmc/12567
>
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2016-02-18 0:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8F1CD504A027484E89249BCD2A7248DD573D15D9@SSIEXCH-MB3.ssi.samsung.com>
2016-02-17 15:21 ` [Lsf-pc] [LSF/MM TOPIC] multi-stream IO hint implementation proposal for LSF/MM 2016 Jan Kara
2016-02-17 23:08 ` Martin K. Petersen
2016-02-17 23:36 ` Dave Chinner
[not found] ` <CAJVOszAJTCGzVP7GBx3AQOvUiE7d8-3eMmpmCjPxD4d0+AGX2g@mail.gmail.com>
2016-02-18 10:21 ` Jan Kara
2016-02-18 0:46 ` Jaegeuk Kim [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=20160218004616.GA97837@jaegeuk.gateway \
--to=jaegeuk@kernel.org \
--cc=changho.c@ssi.samsung.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).