lkml.org 
[lkml]   [2020]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RESENT PATCH RFC v3 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver
Date
Hi Bean,
This patch is ~3,000 lines long.
Is it possible to divide it into a series of a smaller, more reviewable patches?
E.g. it can be something like:
1) Init part I - Read HPB config
2) Init part II - prepare for L2P cache management (introduce here all the new data structures, memory allocation, etc.)
3) L2P cache management - activation / inactivation / eviction handlers
4) Add response API
5) Add prep_fn handler - the flows that contruct HPB-READ command.
Or any other division that makes sense to you.

Also, Is there a way to avoid all those #ifdefs everywhere?

Thanks,
Avri


>
> 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 | 234 +++-
> drivers/scsi/ufs/ufshcd.h | 23 +
> drivers/scsi/ufs/ufshpb.c | 2767
> +++++++++++++++++++++++++++++++++++++
> drivers/scsi/ufs/ufshpb.h | 423 ++++++
> 6 files changed, 3504 insertions(+), 6 deletions(-)
> create mode 100644 drivers/scsi/ufs/ufshpb.c
> create mode 100644 drivers/scsi/ufs/ufshpb.h
>
\
 
 \ /
  Last update: 2020-05-08 13:39    [W:0.185 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site