From: Bean Huo <huobean@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>,
alim.akhtar@samsung.com, avri.altman@wdc.com,
asutoshd@codeaurora.org, jejb@linux.ibm.com,
martin.petersen@oracle.com, stanley.chu@mediatek.com,
beanhuo@micron.com, bvanassche@acm.org, tomas.winkler@intel.com,
hch@infradead.org
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
cang@codeaurora.org
Subject: Re: [RESENT PATCH RFC v3 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver
Date: Fri, 08 May 2020 12:08:03 +0200 [thread overview]
Message-ID: <201b31e72f545ef46a74c7aa8e9cad8a9a81727e.camel@gmail.com> (raw)
In-Reply-To: <38db2ee7-18ff-9263-1cc7-1b9c6f085632@infradead.org>
On Thu, 2020-05-07 at 18:34 -0700, Randy Dunlap wrote:
> Hi,
>
> On 5/4/20 7:20 AM, huobean@gmail.com wrote:
> > diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> > index e2005aeddc2d..0224f224a641 100644
> > --- a/drivers/scsi/ufs/Kconfig
> > +++ b/drivers/scsi/ufs/Kconfig
> > @@ -160,3 +160,65 @@ config SCSI_UFS_BSG
> >
> > Select this if you need a bsg device node for your UFS
> > controller.
> > If unsure, say N.
> > +
> > +config SCSI_UFSHPB
> > + bool "UFS Host Performance Booster (EXPERIMENTAL)"
> > + depends on SCSI_UFSHCD
> > + help
> > + NAND flash-based storage devices, including UFS, have
> > mechanisms to
> > + translate logical addresses of the IO requests to the
> > corresponding
> > + physical addresses of the flash storage. Traditionally, this
> > L2P
> > + mapping data is loaded to the internal SRAM in the storage
> > controller.
> > + When the capacity of storage is larger, a larger size of SRAM
> > for the
> > + L2P map data is required. Since increased SRAM size affects
> > the
> > + manufacturing cost significantly, it is not cost-effective to
> > allocate
> > + all the amount of SRAM needed to keep all the Logical-address
> > to
> > + Physical-address (L2P) map data. Therefore, 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.
> > +
> > + UFS Host Performance Booster (HPB) is a software solution for
> > the
> > + above problem, which uses the host side system memory as a
> > cache for
> > + the FTL L2P mapping table. It does not need additional
> > hardware
> > + support from the host side. By using HPB, the L2P mapping
> > table can be
> > + read from host memory and stored in host-side memory. when
> > performing
>
> Should that be: from device memory and stored in host-side memory.
> ?
>
> Also, s/when/When/
>
>
> > + the read operation, the corresponding L2P information will be
> > sent to
> > + the UFS device along with the reading request. Since the L2P
> > entry is
>
> s/reading/read/
>
> > + provided in the read request, UFS device does not have to
> > load L2P
> > + entry from flash memory to UFS internal SRAM. This will
> > significantly
> > + improve the read performance.
> > +
> > + When selected, this feature will be built in the UFS driver.
> > +
> > + If in doubt, say N.
> > +
> > +config UFSHPB_MAX_MEM_SIZE
> > + int "UFS HPB maximum memory size per controller (in MiB)"
> > + depends on SCSI_UFSHPB
> > + default 128
> > + range 0 65536
> > + help
> > + This parameter defines the maximum UFS HPB memory/cache size
> > in the
> > + host system. The recommended HPB cache size by the UFS device
> > can be
> > + calculated from bHPBRegionSize and
> > wDeviceMaxActiveHPBRegions. The
> > + reference formula can be
>
> s/can be/is/
>
> > +
> > + (bHPBRegionSize(in KB) / 4KB) * 8 *
> > wDeviceMaxActiveHPBRegions.
> > +
> > + The HPB cache in the host system is used to contain L2P
> > mapping
> > + entries. If the allocated HPB cache size is lower than what
> > calculated
>
> than that
>
> > + by the above formula, the use of HPB feature may provide
> > lower
> > + performance advantage. But the system memory resource has the
> > + limitation, we can not let HPB driver allocate its cache at
> > will
> > + according to the UFS device recommendation, so an appropriate
> > size of
> > + the cache for HPB should be specified before you choose to
> > use HPB,
> > + then please enter a non-zero positive integer value.
> > +
> > + Nevertheless, if you want to leave this to the HPB driver,
> > and let the
> > + HPB driver allocate the HPB cache based on the recommendation
> > of the
> > + UFS device. Just give 0 value to this parameter.
> > +
> > + Leave the default value if unsure.
>
> thanks.
Hi Randy
Thanks for your review. I will change them based on your
comments.
thanks,
Bean
next prev parent reply other threads:[~2020-05-08 10:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 14:20 [RESENT PATCH RFC v3 0/5] scsi: ufs: add UFS Host Performance Booster(HPB) support huobean
2020-05-04 14:20 ` [RESENT PATCH RFC v3 1/5] scsi; ufs: add device descriptor for Host Performance Booster huobean
2020-05-08 0:59 ` Bart Van Assche
2020-05-08 9:09 ` Bean Huo
2020-05-04 14:20 ` [RESENT PATCH RFC v3 2/5] scsi: ufs: make ufshcd_read_unit_desc_param() non-static func huobean
2020-05-04 14:20 ` [RESENT PATCH RFC v3 3/5] scsi: ufs: add ufs_features parameter in structure ufs_dev_info huobean
2020-05-08 1:02 ` Bart Van Assche
2020-05-08 9:15 ` Bean Huo
2020-05-04 14:20 ` [RESENT PATCH RFC v3 4/5] scsi: ufs: add unit and geometry parameters for HPB huobean
2020-05-08 1:04 ` Bart Van Assche
2020-05-08 10:15 ` Bean Huo
2020-05-04 14:20 ` [RESENT PATCH RFC v3 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver huobean
2020-05-08 1:34 ` Randy Dunlap
2020-05-08 10:08 ` Bean Huo [this message]
2020-05-08 3:21 ` Bart Van Assche
2020-05-08 14:44 ` Bean Huo
2020-05-08 20:11 ` Bart Van Assche
2020-05-08 11:38 ` Avri Altman
2020-05-08 12:15 ` Bean Huo
2020-05-08 14:26 ` Alim Akhtar
2020-05-08 14:59 ` Bean Huo
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=201b31e72f545ef46a74c7aa8e9cad8a9a81727e.camel@gmail.com \
--to=huobean@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=hch@infradead.org \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=rdunlap@infradead.org \
--cc=stanley.chu@mediatek.com \
--cc=tomas.winkler@intel.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