Linux-SCSI Archive on lore.kernel.org
 help / color / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Christoph Hellwig <hch@infradead.org>,
	yongmyung lee <ymhungry.lee@samsung.com>
Cc: Avri Altman <Avri.Altman@wdc.com>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ALIM AKHTAR <alim.akhtar@samsung.com>,
	"asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
	Zang Leigang <zangleigang@hisilicon.com>,
	Avi Shchislowski <Avi.Shchislowski@wdc.com>,
	Bean Huo <beanhuo@micron.com>,
	"cang@codeaurora.org" <cang@codeaurora.org>,
	"stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
	MOHAMMED RAFIQ KAMAL BASHA <md.rafiq@samsung.com>,
	Sang-yoon Oh <sangyoon.oh@samsung.com>,
	Jinyoung CHOI <j-young.choi@samsung.com>,
	Adel Choi <adel.choi@samsung.com>,
	BoRam Shin <boram.shin@samsung.com>,
	Sung-Jun Park <sungjun07.park@samsung.com>,
	Daejun Park <daejun7.park@samsung.com>
Subject: Re: Another approach of UFSHPB
Date: Fri, 22 May 2020 09:35:21 -0700
Message-ID: <224ba721-b80e-f018-a3f9-a2f56ecef8d6@acm.org> (raw)
In-Reply-To: <e1e81ad1-2681-9dbe-34aa-85f4e5559927@acm.org>

On 2020-05-20 14:19, Bart Van Assche wrote:
> On 2020-05-20 10:55, Christoph Hellwig wrote:
>> HPB is a completely fucked up concept and we shoud not merge it at all.
>> Especially not with a crazy bullshit vendor extension layer that makes
>> it even easier for vendors to implement even worse things than the
>> already horrible spec says.  Just stop this crap and implement sane
>> interfaces for the next generation hardware instead of wasting your
>> time on this idiotic idea.
> 
> What exactly is it that you are not happy about? Is it the concept of
> using host memory to store L2P translation information or how that
> concept has been translated into SCSI commands (HPB READ BUFFER, HPB
> READ and HPB WRITE BUFFER)?
> 
> In the former case: aren't Open-Channel SSDs another example of storage
> devices for which the L2P translation tables are maintained in host
> memory? Didn't the driver for Fusion-io SSDs also maintain the L2P
> mapping in host memory?
> 
> Do you agree that HPB UFS storage devices are already being used widely
> and hence that not accepting this functionality in the upstream kernel
> will force users of HPB devices to maintain HPB code outside the kernel
> tree? Isn't one of the goals of the Linux kernel project to increase its
> user base?

The following quote from
https://www.anandtech.com/show/13474/the-google-pixel-3-review/2 is
interesting: "Another big improvement for file I/O is the implementation
of “Host Performance Booster” in the kernel and UFS controller firmware
stack. HPB is essentially caching of the NAND chip’s FTL (flash
translation layer) L2P (logical to physical) mapping tables into the
hosts (SoCs) main memory. This allows the host driver to look up the
target L2P entry directly without betting on UFS’s limited SRAM to have
a cache-hit, reducing latency and greatly increasing random read
performance. The authors of the feature showcase an improvement of
59-67% in random I/O read performance due to the new feature. It’s worth
to mention that traditional Android I/O benchmarks won’t be able to show
this as as those tend to test read speeds with the files they’ve just
created."

Given the cost of SRAM in embedded controllers I think there is a strong
incentive for manufacturers of flash storage devices to reduce the
amount of SRAM on the storage controller. I think this means that
proposals to use host memory for caching L2P mappings will keep popping
up, no matter what we tell the storage controller vendors about what we
think about such a design.

Bart.

  reply index

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 10:30 [RFC PATCH 00/13] scsi: ufs: Add HPB Support Avri Altman
2020-05-15 10:30 ` [RFC PATCH 01/13] scsi: ufs: Add HPB parameters Avri Altman
2020-05-15 10:30 ` [RFC PATCH 02/13] scsi: ufshpb: Init part I - Read HPB config Avri Altman
2020-05-15 15:33   ` Randy Dunlap
2020-05-16  1:46   ` Bart Van Assche
2020-05-16  1:57   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 03/13] scsi: scsi_dh: Introduce scsi_dh_ufshpb Avri Altman
2020-05-16  1:48   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 04/13] scsi: ufs: ufshpb: Init part II - Attach scsi device Avri Altman
2020-05-16  1:52   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 05/13] scsi: ufs: ufshpb: Disable HPB if no HPB-enabled luns Avri Altman
2020-05-16  2:02   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 06/13] scsi: scsi_dh: ufshpb: Prepare for L2P cache management Avri Altman
2020-05-16  2:13   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 07/13] scsi: scsi_dh: ufshpb: Add ufshpb state machine Avri Altman
2020-05-16  2:44   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 08/13] scsi: dh: ufshpb: Activate pinned regions Avri Altman
2020-05-15 10:30 ` [RFC PATCH 09/13] scsi: ufshpb: Add response API Avri Altman
2020-05-16  3:06   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 10/13] scsi: dh: ufshpb: Add ufshpb_set_params Avri Altman
2020-05-15 10:30 ` [RFC PATCH 11/13] scsi: Allow device handler set their own CDB Avri Altman
2020-05-16  3:19   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 12/13] scsi: dh: ufshpb: Add prep_fn handler Avri Altman
2020-05-16  3:40   ` Bart Van Assche
2020-05-15 10:30 ` [RFC PATCH 13/13] scsi: scsi_dh: ufshpb: Add "Cold" subregions timer Avri Altman
2020-05-16  3:50 ` [RFC PATCH 00/13] scsi: ufs: Add HPB Support Bart Van Assche
2020-05-16  9:14   ` Avri Altman
2020-05-16 17:14     ` Bart Van Assche
     [not found]     ` <CGME20200516171420epcas2p108c570904c5117c3654d71e0a2842faa@epcms2p7>
2020-05-19 22:31       ` Another approach of UFSHPB yongmyung lee
2020-05-20 17:55         ` Christoph Hellwig
2020-05-20 21:19           ` Bart Van Assche
2020-05-22 16:35             ` Bart Van Assche [this message]
2020-05-22 16:49         ` Bart Van Assche
     [not found]         ` <CGME20200516171420epcas2p108c570904c5117c3654d71e0a2842faa@epcms2p4>
2020-05-25  5:40           ` Daejun Park
2020-05-25 14:56             ` Bart Van Assche
2020-05-26  6:15               ` Avri Altman
2020-05-26 17:03                 ` Bart Van Assche
     [not found]                 ` <CGME20200516171420epcas2p108c570904c5117c3654d71e0a2842faa@epcms2p3>
2020-05-27  9:11                   ` Daejun Park
2020-05-27 11:46                     ` 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=224ba721-b80e-f018-a3f9-a2f56ecef8d6@acm.org \
    --to=bvanassche@acm.org \
    --cc=Avi.Shchislowski@wdc.com \
    --cc=Avri.Altman@wdc.com \
    --cc=adel.choi@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=beanhuo@micron.com \
    --cc=boram.shin@samsung.com \
    --cc=cang@codeaurora.org \
    --cc=daejun7.park@samsung.com \
    --cc=hch@infradead.org \
    --cc=j-young.choi@samsung.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=md.rafiq@samsung.com \
    --cc=sangyoon.oh@samsung.com \
    --cc=stanley.chu@mediatek.com \
    --cc=sungjun07.park@samsung.com \
    --cc=ymhungry.lee@samsung.com \
    --cc=zangleigang@hisilicon.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

Linux-SCSI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-scsi/0 linux-scsi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-scsi linux-scsi/ https://lore.kernel.org/linux-scsi \
		linux-scsi@vger.kernel.org
	public-inbox-index linux-scsi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-scsi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git