| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 16 Apr 2020 14:35:30 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: huobean@...il.com, alim.akhtar@...sung.com, avri.altman@....com,
asutoshd@...eaurora.org, jejb@...ux.ibm.com,
martin.petersen@...cle.com, stanley.chu@...iatek.com,
beanhuo@...ron.com, bvanassche@....org, tomas.winkler@...el.com,
cang@...eaurora.org
Cc: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB)
driver
Hi--
A few Kconfig changes for you to consider:
On 4/16/20 1:31 PM, huobean@...il.com wrote:
> From: Bean Huo <beanhuo@...ron.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@...ron.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
Powered by blists - more mailing lists