The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: huobean@gmail.com, 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,
	cang@codeaurora.org
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver
Date: Thu, 16 Apr 2020 14:35:30 -0700	[thread overview]
Message-ID: <d8d3ccea-95dd-184b-3099-b168becbf00d@infradead.org> (raw)
In-Reply-To: <20200416203126.1210-6-beanhuo@micron.com>

Hi--

A few Kconfig changes for you to consider:


On 4/16/20 1:31 PM, huobean@gmail.com wrote:
> From: Bean Huo <beanhuo@micron.com>
> 
> This patch is to add support for the UFS Host Performance Booster (HPB v1.0),
> which is used to improve UFS read performance, especially for the random read.
> 
> NAND flash-based storage devices, including UFS, have mechanisms to translate
> logical addresses of 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.
> 
> The HPB is a software solution for the above problem, which uses the host’s
> 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. while
> reading the operation, the corresponding L2P information will be sent to the
> UFS device along with the reading request. Since the L2P entry is provided in
> the read request, UFS device does not have to load L2P entry from flash memory.
> This will significantly improve random read performance.
> 
> Signed-off-by: Bean Huo <beanhuo@micron.com>
> ---
>  drivers/scsi/ufs/Kconfig  |   62 +
>  drivers/scsi/ufs/Makefile |    1 +
>  drivers/scsi/ufs/ufshcd.c |   55 +-
>  drivers/scsi/ufs/ufshcd.h |   10 +
>  drivers/scsi/ufs/ufshpb.c | 3279 +++++++++++++++++++++++++++++++++++++
>  drivers/scsi/ufs/ufshpb.h |  450 +++++
>  6 files changed, 3851 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/scsi/ufs/ufshpb.c
>  create mode 100644 drivers/scsi/ufs/ufshpb.h
> 
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index e2005aeddc2d..48704062861a 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. while reading

	            ^??^                                        When performing a

> +	  the operation, the corresponding L2P information will be sent to the

	  read operation, the

> +	  UFS device along with the reading request. Since the L2P entry is

	                        the read request.

> +	  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
> +
> +		(bHPBRegionSize(in KB) / 4KB) * 8 * wDeviceMaxActiveHPBRegions.
> +
> +	  The HPB cache in the host system is used to contain L2P mapping entry.

	                                                                  entries.

> +	  If the allocated HPB cache size is lower than what calculated by the

	                                                that

> +	  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 input a

	                                                    then enter a

> +	  non-zero positive integer value.
> +
> +	  Nevertheless, if you want to leave this right to the HPB driver, and

	                               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.

	             device, just

> +
> +	  Leave the default value if unsure.

gday.
-- 
~Randy


  reply	other threads:[~2020-04-16 21:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 20:31 [PATCH v2 0/5] UFS Host Performance Booster (HPB v1.0) driver huobean
2020-04-16 20:31 ` [PATCH v2 1/5] scsi; ufs: add device descriptor for Host Performance Booster huobean
2020-04-22 23:11   ` Bart Van Assche
2020-04-23 11:01     ` [EXT] " Bean Huo (beanhuo)
2020-04-23 17:57       ` Bart Van Assche
2020-04-16 20:31 ` [PATCH v2 2/5] scsi: ufs: make ufshcd_read_unit_desc_param() non-static func huobean
2020-04-16 20:31 ` [PATCH v2 3/5] scsi: ufs: add ufs_features parameter in structure ufs_dev_info huobean
2020-04-22 23:13   ` Bart Van Assche
2020-04-16 20:31 ` [PATCH v2 4/5] scsi: ufs: add unit and geometry parameters for HPB huobean
2020-04-16 20:31 ` [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver huobean
2020-04-16 21:35   ` Randy Dunlap [this message]
2020-04-23  0:00   ` Bart Van Assche
2020-04-24  9:51     ` [EXT] " Bean Huo (beanhuo)
2020-04-24 18:17     ` Avri Altman
2020-04-24 20:02       ` [EXT] " Bean Huo (beanhuo)
2020-04-25  8:59       ` Avri Altman
2020-04-25 17:51         ` Bart Van Assche
2020-04-27  6:13           ` Avri Altman
2020-04-28  3:36             ` Bart Van Assche
2020-04-28  8:14               ` Avri Altman
2020-04-28 11:59                 ` Bean Huo
2020-04-30  7:23                   ` Avri Altman
2020-04-30 12:45                     ` Bean Huo
2020-05-02 16:19                       ` Avri Altman
2020-04-28  9:12               ` Bean Huo
2020-04-25 18:07   ` Bart Van Assche
2020-04-26 22:03     ` Bean Huo
2020-04-22  6:43 ` [PATCH v2 0/5] UFS Host Performance Booster (HPB v1.0) driver Christoph Hellwig
2020-04-22 22:09   ` [EXT] " Bean Huo (beanhuo)
2020-04-23  8:26     ` Avri Altman

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=d8d3ccea-95dd-184b-3099-b168becbf00d@infradead.org \
    --to=rdunlap@infradead.org \
    --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=huobean@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --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