linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanley Chu <stanley.chu@mediatek.com>
To: <daejun7.park@samsung.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"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>,
	"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>,
	JinHwan Park <jh.i.park@samsung.com>,
	Javier Gonzalez <javier.gonz@samsung.com>,
	Sung-Jun Park <sungjun07.park@samsung.com>,
	Jinyoung CHOI <j-young.choi@samsung.com>,
	Dukhyun Kwon <d_hyun.kwon@samsung.com>,
	Keoseong Park <keosung.park@samsung.com>,
	Jaemyung Lee <jaemyung.lee@samsung.com>,
	Jieon Seol <jieon.seol@samsung.com>
Subject: Re: [PATCH v34 1/4] scsi: ufs: Introduce HPB feature
Date: Mon, 17 May 2021 17:40:15 +0800	[thread overview]
Message-ID: <1621244415.21674.8.camel@mtkswgap22> (raw)
In-Reply-To: <20210428232340epcms2p4b8b34353e93495895b76f062207a6697@epcms2p4>

Hi Daejun,

Sorry I lost the cover letter so I replied this mail instead.

For this series,

Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Tested-by: Stanley Chu <stanley.chu@mediatek.com>


On Thu, 2021-04-29 at 08:23 +0900, Daejun Park wrote:
> This is a patch for the HPB initialization and adds HPB function calls to
> UFS core driver.
> 
> NAND flash-based storage devices, including UFS, have mechanisms to
> translate logical addresses of IO requests to the corresponding physical
> addresses of the flash storage.
> In UFS, Logical-address-to-Physical-address (L2P) map data, which is
> required to identify the physical address for the requested IOs, can only
> be partially stored in SRAM from NAND flash. Due to this partial loading,
> accessing the flash address area where the L2P information for that address
> is not loaded in the SRAM can result in serious performance degradation.
> 
> The basic concept of HPB is to cache L2P mapping entries in host system
> memory so that both physical block address (PBA) and logical block address
> (LBA) can be delivered in HPB read command.
> The HPB READ command allows to read data faster than a read command in UFS
> since it provides the physical address (HPB Entry) of the desired logical
> block in addition to its logical address. The UFS device can access the
> physical block in NAND directly without searching and uploading L2P mapping
> table. This improves read performance because the NAND read operation for
> uploading L2P mapping table is removed.
> 
> In HPB initialization, the host checks if the UFS device supports HPB
> feature and retrieves related device capabilities. Then, some HPB
> parameters are configured in the device.
> 
> 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
>  - RAM: 8GB
>  - 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 |
> +-------+----------+----------+-------+
> 
> We also measured HPB performance using iozone.
> 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  |
> +----------+--------+---------+


  reply	other threads:[~2021-05-17  9:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210428232257epcms2p8602b29d63529fca8a06010a21157d5cb@epcms2p8>
2021-04-28 23:22 ` [PATCH v34 0/4] scsi: ufs: Add Host Performance Booster Support Daejun Park
     [not found]   ` <CGME20210428232257epcms2p8602b29d63529fca8a06010a21157d5cb@epcms2p3>
2021-04-28 23:24     ` [PATCH v34 2/4] scsi: ufs: L2P map management for HPB read Daejun Park
     [not found]   ` <CGME20210428232257epcms2p8602b29d63529fca8a06010a21157d5cb@epcms2p2>
2021-04-28 23:25     ` [PATCH v34 3/4] scsi: ufs: Prepare HPB read for cached sub-region Daejun Park
2021-04-29  6:44   ` [PATCH v34 0/4] scsi: ufs: Add Host Performance Booster Support Avri Altman
     [not found]   ` <CGME20210428232257epcms2p8602b29d63529fca8a06010a21157d5cb@epcms2p4>
2021-04-28 23:23     ` [PATCH v34 1/4] scsi: ufs: Introduce HPB feature Daejun Park
2021-05-17  9:40       ` Stanley Chu [this message]
2021-04-28 23:25     ` [PATCH v34 4/4] scsi: ufs: Add HPB 2.0 support Daejun Park
2021-05-20 12:32       ` Avri Altman
2021-05-21  8:13     ` 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=1621244415.21674.8.camel@mtkswgap22 \
    --to=stanley.chu@mediatek.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=d_hyun.kwon@samsung.com \
    --cc=daejun7.park@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=huobean@gmail.com \
    --cc=j-young.choi@samsung.com \
    --cc=jaemyung.lee@samsung.com \
    --cc=javier.gonz@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=jh.i.park@samsung.com \
    --cc=jieon.seol@samsung.com \
    --cc=keosung.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sungjun07.park@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).