From: Daejun Park <daejun7.park@samsung.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Daejun Park <daejun7.park@samsung.com>
Cc: "avri.altman@wdc.com" <avri.altman@wdc.com>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
"stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
"cang@codeaurora.org" <cang@codeaurora.org>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"huobean@gmail.com" <huobean@gmail.com>,
ALIM AKHTAR <alim.akhtar@samsung.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sung-Jun Park <sungjun07.park@samsung.com>,
yongmyung lee <ymhungry.lee@samsung.com>,
Jinyoung CHOI <j-young.choi@samsung.com>,
Adel Choi <adel.choi@samsung.com>,
BoRam Shin <boram.shin@samsung.com>,
SEUNGUK SHIN <seunguk.shin@samsung.com>
Subject: RE: Re: [PATCH v14 0/3] scsi: ufs: Add Host Performance Booster Support
Date: Fri, 18 Dec 2020 10:05:20 +0900 [thread overview]
Message-ID: <20201218010520epcms2p1f7994bde414008ea1f44c733350308db@epcms2p1> (raw)
In-Reply-To: <X9ncUJH/vHO7Luqi@kroah.com>
Hi, Greg
> > NAND flash memory-based storage devices use Flash Translation Layer (FTL)
> > to translate logical addresses of I/O requests to corresponding flash
> > memory addresses. Mobile storage devices typically have RAM with
> > constrained size, thus lack in memory to keep the whole mapping table.
> > Therefore, mapping tables are partially retrieved from NAND flash on
> > demand, causing random-read performance degradation.
> >
> > To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB
> > (Host Performance Booster) which uses host system memory as a cache for the
> > FTL mapping table. By using HPB, FTL data can be read from host memory
> > faster than from NAND flash memory.
> >
> > The current version only supports the DCM (device control mode).
> > This patch consists of 3 parts to support HPB feature.
> >
> > 1) HPB probe and initialization process
> > 2) READ -> HPB READ using cached map information
> > 3) L2P (logical to physical) map management
> >
> > In the HPB probe and init process, the device information of the UFS is
> > queried. After checking supported features, the data structure for the HPB
> > is initialized according to the device information.
> >
> > A read I/O in the active sub-region where the map is cached is changed to
> > HPB READ by the HPB.
> >
> > The HPB manages the L2P map using information received from the
> > device. For active sub-region, the HPB caches through ufshpb_map
> > request. For the in-active region, the HPB discards the L2P map.
> > When a write I/O occurs in an active sub-region area, associated dirty
> > bitmap checked as dirty for preventing stale read.
> >
> > HPB is shown to have a performance improvement of 58 - 67% for random read
> > workload. [1]
> >
> > We measured the total start-up time of popular applications and observed
> > the difference by enabling the HPB.
> > Popular applications are 12 game apps and 24 non-game apps. Each target
> > applications were launched in order. The cycle consists of running 36
> > applications in sequence. We repeated the cycle for observing performance
> > improvement by L2P mapping cache hit in HPB.
> >
> > The Following is experiment environment:
> > - kernel version: 4.4.0
> > - UFS 2.1 (64GB)
> >
> > Result:
> > +-------+----------+----------+-------+
> > | cycle | baseline | with HPB | diff |
> > +-------+----------+----------+-------+
> > | 1 | 272.4 | 264.9 | -7.5 |
> > | 2 | 250.4 | 248.2 | -2.2 |
> > | 3 | 226.2 | 215.6 | -10.6 |
> > | 4 | 230.6 | 214.8 | -15.8 |
> > | 5 | 232.0 | 218.1 | -13.9 |
> > | 6 | 231.9 | 212.6 | -19.3 |
> > +-------+----------+----------+-------+
>
> I feel this was burried in the 00 email, shouldn't it go into the 01
> commit changelog so that you can see this?
Sure, I will move this result to 01 commit log.
> But why does the "cycle" matter here?
I think iteration minimizes other factors that affect the start-up time of
application.
> Can you run a normal benchmark, like fio, on here so we can get some
> numbers we know how to compare to other systems with, and possible
> reproduct it ourselves? I'm sure fio will easily show random read
> performance increases, right?
Here is my iozone script:
iozone -r 4k -+n -i2 -ecI -t 16 -l 16 -u 16
-s $IO_RANGE/16 -F mnt/tmp_1 mnt/tmp_2 mnt/tmp_3 mnt/tmp_4
mnt/tmp_5 mnt/tmp_6 mnt/tmp_7 mnt/tmp_8 mnt/tmp_9 mnt/tmp_10 mnt/tmp_11
mnt/tmp_12 mnt/tmp_13 mnt/tmp_14 mnt/tmp_15 mnt/tmp_16
Result:
+----------+--------+---------+
| IO range | HPB on | HPB off |
+----------+--------+---------+
| 1 GB | 294.8 | 300.87 |
| 4 GB | 293.51 | 179.35 |
| 8 GB | 294.85 | 162.52 |
| 16 GB | 293.45 | 156.26 |
| 32 GB | 277.4 | 153.25 |
+----------+--------+---------+
Thanks,
Daejun
next prev parent reply other threads:[~2020-12-18 1:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20201215082235epcms2p88c9d8fd4dc773f6a4901dab241063306@epcms2p5>
2020-12-16 2:44 ` [PATCH v14 0/3] scsi: ufs: Add Host Performance Booster Support Daejun Park
[not found] ` <CGME20201215082235epcms2p88c9d8fd4dc773f6a4901dab241063306@epcms2p2>
2020-12-16 2:45 ` Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature Daejun Park
2020-12-16 9:01 ` Greg KH
[not found] ` <CGME20201215082235epcms2p88c9d8fd4dc773f6a4901dab241063306@epcms2p1>
2020-12-17 5:21 ` Daejun Park
2020-12-17 6:17 ` Greg KH
2020-12-18 1:05 ` Daejun Park [this message]
2020-12-18 1:58 ` [PATCH v14 0/3] scsi: ufs: Add Host Performance Booster Support Bart Van Assche
2020-12-18 2:01 ` Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature Stanley Chu
2020-12-18 2:15 ` Daejun Park
[not found] ` <CGME20201215082235epcms2p88c9d8fd4dc773f6a4901dab241063306@epcms2p6>
2020-12-16 2:47 ` [PATCH v14 3/3] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
2020-12-16 10:07 ` [PATCH v14 0/3] scsi: ufs: Add Host Performance Booster Support Greg KH
[not found] ` <CGME20201215082235epcms2p88c9d8fd4dc773f6a4901dab241063306@epcms2p7>
2020-12-16 2:46 ` [PATCH v14 2/3] scsi: ufs: L2P map management for HPB read Daejun Park
2020-12-18 2:16 ` Re: [PATCH v14 0/3] scsi: ufs: Add Host Performance Booster Support Daejun Park
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=20201218010520epcms2p1f7994bde414008ea1f44c733350308db@epcms2p1 \
--to=daejun7.park@samsung.com \
--cc=adel.choi@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=boram.shin@samsung.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=huobean@gmail.com \
--cc=j-young.choi@samsung.com \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=seunguk.shin@samsung.com \
--cc=stanley.chu@mediatek.com \
--cc=sungjun07.park@samsung.com \
--cc=ymhungry.lee@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).