| Message ID | 963815509.21594636682161.JavaMail.epsvc@epcpadp2 (mailing list archive) |
|---|---|
| Headers | show |
| Series | scsi: ufs: Add Host Performance Booster Support | expand |
Hello All,
My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D team in which Avri is a member of.
As the review process of HPB is progressing very constructively, we are getting more and more requests from OEMs, Inquiring about HPB in general, and host control mode in particular.
Their main concern is that HPB will make it to 5.9 merge window, but the host control mode patches will not.
Thus, because of recent Google's GKI, the next Android LTS might not include HPB with host control mode.
Aside of those requests, initial host control mode testing are showing promising prospective with respect of performance gain.
What would be, in your opinion, the best policy that host control mode is included in next Android LTS?
Thanks,
Avi
-----Original Message-----
From: linux-scsi-owner@vger.kernel.org <linux-scsi-owner@vger.kernel.org> On Behalf Of Daejun Park
Sent: Monday, July 13, 2020 1:34 PM
To: Avri Altman <Avri.Altman@wdc.com>; jejb@linux.ibm.com; martin.petersen@oracle.com; asutoshd@codeaurora.org; beanhuo@micron.com; stanley.chu@mediatek.com; cang@codeaurora.org; bvanassche@acm.org; tomas.winkler@intel.com; ALIM AKHTAR <alim.akhtar@samsung.com>; Daejun Park <daejun7.park@samsung.com>
Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Sang-yoon Oh <sangyoon.oh@samsung.com>; Sung-Jun Park <sungjun07.park@samsung.com>; yongmyung lee <ymhungry.lee@samsung.com>; Jinyoung CHOI <j-young.choi@samsung.com>; Adel Choi <adel.choi@samsung.com>; BoRam Shin <boram.shin@samsung.com>
Subject: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support
CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.
Changelog:
v5 -> v6
Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405
v4 -> v5
Delete unused macro define.
v3 -> v4
1. Cleanup.
v2 -> v3
1. Add checking input module parameter value.
2. Change base commit from 5.8/scsi-queue to 5.9/scsi-queue.
3. Cleanup for unused variables and label.
v1 -> v2
1. Change the full boilerplate text to SPDX style.
2. Adopt dynamic allocation for sub-region data structure.
3. Cleanup.
NAND flash memory-based storage devices use Flash Translation Layer (FTL) to translate logical addresses of I/O requests to corresponding flash memory addresses. Mobile storage devices typically have RAM with constrained size, thus lack in memory to keep the whole mapping table.
Therefore, mapping tables are partially retrieved from NAND flash on demand, causing random-read performance degradation.
To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB (Host Performance Booster) which uses host system memory as a cache for the FTL mapping table. By using HPB, FTL data can be read from host memory faster than from NAND flash memory.
The current version only supports the DCM (device control mode).
This patch consists of 4 parts to support HPB feature.
1) UFS-feature layer
2) HPB probe and initialization process
3) READ -> HPB READ using cached map information
4) L2P (logical to physical) map management
The UFS-feature is an additional layer to avoid the structure in which the UFS-core driver and the UFS-feature are entangled with each other in a single module.
By adding the layer, UFS-features composed of various combinations can be supported. Also, even if a new feature is added, modification of the UFS-core driver can be minimized.
In the HPB probe and init process, the device information of the UFS is queried. After checking supported features, the data structure for the HPB is initialized according to the device information.
A read I/O in the active sub-region where the map is cached is changed to HPB READ by the HPB module.
The HPB module manages the L2P map using information received from the device. For active sub-region, the HPB module caches through ufshpb_map request. For the in-active region, the HPB module discards the L2P map.
When a write I/O occurs in an active sub-region area, associated dirty bitmap checked as dirty for preventing stale read.
HPB is shown to have a performance improvement of 58 - 67% for random read workload. [1]
This series patches are based on the 5.9/scsi-queue branch.
[1]:
https://www.usenix.org/conference/hotstorage17/program/presentation/jeong
Daejun park (5):
scsi: ufs: Add UFS feature related parameter
scsi: ufs: Add UFS feature layer
scsi: ufs: Introduce HPB module
scsi: ufs: L2P map management for HPB read
scsi: ufs: Prepare HPB read for cached sub-region
drivers/scsi/ufs/Kconfig | 9 +
drivers/scsi/ufs/Makefile | 3 +-
drivers/scsi/ufs/ufs.h | 12 +
drivers/scsi/ufs/ufsfeature.c | 148 +++
drivers/scsi/ufs/ufsfeature.h | 69 ++
drivers/scsi/ufs/ufshcd.c | 19 +
drivers/scsi/ufs/ufshcd.h | 2 +
drivers/scsi/ufs/ufshpb.c | 1997 ++++++++++++++++++++++++++++++++++++
drivers/scsi/ufs/ufshpb.h | 232 +++++
9 files changed, 2490 insertions(+), 1 deletion(-) created mode 100644 drivers/scsi/ufs/ufsfeature.c created mode 100644 drivers/scsi/ufs/ufsfeature.h created mode 100644 drivers/scsi/ufs/ufshpb.c created mode 100644 drivers/scsi/ufs/ufshpb.h
Hi Avri, > -----Original Message----- > From: Daejun Park <daejun7.park@samsung.com> > Sent: 13 July 2020 16:04 > To: avri.altman@wdc.com; jejb@linux.ibm.com; martin.petersen@oracle.com; > asutoshd@codeaurora.org; beanhuo@micron.com; > stanley.chu@mediatek.com; cang@codeaurora.org; bvanassche@acm.org; > tomas.winkler@intel.com; ALIM AKHTAR <alim.akhtar@samsung.com>; Daejun > Park <daejun7.park@samsung.com> > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Sang-yoon Oh > <sangyoon.oh@samsung.com>; Sung-Jun Park > <sungjun07.park@samsung.com>; yongmyung lee > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j-young.choi@samsung.com>; > Adel Choi <adel.choi@samsung.com>; BoRam Shin > <boram.shin@samsung.com> > Subject: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > Changelog: > > v5 -> v6 > Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 > If no further comments, can this series have your Reviewed-by or Acked-by tag, so that this can be taken for 5.9? Thanks! > v4 -> v5 > Delete unused macro define.
On 2020-07-15 11:34, Avi Shchislowski wrote: > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D team in which Avri is a member of. > As the review process of HPB is progressing very constructively, we are getting more and more requests from OEMs, Inquiring about HPB in general, and host control mode in particular. > > Their main concern is that HPB will make it to 5.9 merge window, but the host control mode patches will not. > Thus, because of recent Google's GKI, the next Android LTS might not include HPB with host control mode. > > Aside of those requests, initial host control mode testing are showing promising prospective with respect of performance gain. > > What would be, in your opinion, the best policy that host control mode is included in next Android LTS? Hi Avi, Are you perhaps referring to the HPB patch series that has already been posted? Although I'm not sure of this, I think that the SCSI maintainer expects more Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken the time to review and/or test this patch series? Thanks, Bart.
On Wed, 2020-07-15 at 18:34 +0000, Avi Shchislowski wrote: > Hello All, > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D > team in which Avri is a member of. > As the review process of HPB is progressing very constructively, we > are getting more and more requests from OEMs, Inquiring about HPB in > general, and host control mode in particular. > > Their main concern is that HPB will make it to 5.9 merge window, but > the host control mode patches will not. > Thus, because of recent Google's GKI, the next Android LTS might not > include HPB with host control mode. > > Aside of those requests, initial host control mode testing are > showing promising prospective with respect of performance gain. > > What would be, in your opinion, the best policy that host control > mode is included in next Android LTS? > > Thanks, > Avi > Hi Avi IMO, no matter how did the driver implement, if you truly want the HPB host mode driver you mentioned to be mainlined in the upstream Linux, the best policy is that you should first post the driver in the SCSI maillist community, let us firstly review here. I didn't see your driver, I don't know how to provide the correct answer. Thanks, Bean
On Wed, 2020-07-15 at 18:34 +0000, Avi Shchislowski wrote: > Hello All, > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D > team in which Avri is a member of. > As the review process of HPB is progressing very constructively, we > are getting more and more requests from OEMs, Inquiring about HPB in > general, and host control mode in particular. > > Their main concern is that HPB will make it to 5.9 merge window, but > the host control mode patches will not. > Thus, because of recent Google's GKI, the next Android LTS might not > include HPB with host control mode. > > Aside of those requests, initial host control mode testing are > showing promising prospective with respect of performance gain. > > What would be, in your opinion, the best policy that host control > mode is included in next Android LTS? > > Thanks, > Avi > Hi Avi IMO, no matter how did the driver implement, if you truly want the HPB host mode driver you mentioned to be mainlined in the upstream Linux, the best policy is that you should first post the driver in the SCSI maillist community, let us firstly review here. I didn't see your driver, I don't know how to provide the correct answer. Thanks, Bean
> -----Original Message----- > From: Bart Van Assche <bvanassche@acm.org> > Sent: Thursday, July 16, 2020 4:42 AM > To: Avi Shchislowski <Avi.Shchislowski@wdc.com>; > daejun7.park@samsung.com; Avri Altman <Avri.Altman@wdc.com>; > jejb@linux.ibm.com; martin.petersen@oracle.com; asutoshd@codeaurora.org; > beanhuo@micron.com; stanley.chu@mediatek.com; cang@codeaurora.org; > tomas.winkler@intel.com; ALIM AKHTAR <alim.akhtar@samsung.com> > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Sang-yoon Oh > <sangyoon.oh@samsung.com>; Sung-Jun Park > <sungjun07.park@samsung.com>; yongmyung lee > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j- > young.choi@samsung.com>; Adel Choi <adel.choi@samsung.com>; BoRam > Shin <boram.shin@samsung.com> > Subject: Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > CAUTION: This email originated from outside of Western Digital. Do not click on > links or open attachments unless you recognize the sender and know that the > content is safe. > > > On 2020-07-15 11:34, Avi Shchislowski wrote: > > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D team > in which Avri is a member of. > > As the review process of HPB is progressing very constructively, we are getting > more and more requests from OEMs, Inquiring about HPB in general, and host > control mode in particular. > > > > Their main concern is that HPB will make it to 5.9 merge window, but the host > control mode patches will not. > > Thus, because of recent Google's GKI, the next Android LTS might not include > HPB with host control mode. > > > > Aside of those requests, initial host control mode testing are showing > promising prospective with respect of performance gain. > > > > What would be, in your opinion, the best policy that host control mode is > included in next Android LTS? > > Hi Avi, > > Are you perhaps referring to the HPB patch series that has already been posted? > Although I'm not sure of this, I think that the SCSI maintainer expects more > Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken the > time to review and/or test this patch series? > > Thanks, > > Bart. Yes, I am referring to the current proposal which I am replying to: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support This proposal does not contains host mode, hence our customers concern. What would be, in your opinion, the best policy that host control mode is included in next Android LTS assuming it will be based on kernel v5.9 ? Thanks, Avi
On Thu, Jul 16, 2020 at 10:00:57AM +0000, Avi Shchislowski wrote: > > On 2020-07-15 11:34, Avi Shchislowski wrote: > > > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D team > > in which Avri is a member of. > > > As the review process of HPB is progressing very constructively, we are getting > > more and more requests from OEMs, Inquiring about HPB in general, and host > > control mode in particular. > > > > > > Their main concern is that HPB will make it to 5.9 merge window, but the host > > control mode patches will not. > > > Thus, because of recent Google's GKI, the next Android LTS might not include > > HPB with host control mode. > > > > > > Aside of those requests, initial host control mode testing are showing > > promising prospective with respect of performance gain. > > > > > > What would be, in your opinion, the best policy that host control mode is > > included in next Android LTS? > > > > Hi Avi, > > > > Are you perhaps referring to the HPB patch series that has already been posted? > > Although I'm not sure of this, I think that the SCSI maintainer expects more > > Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken the > > time to review and/or test this patch series? > > > > Thanks, > > > > Bart. > > Yes, I am referring to the current proposal which I am replying to: > [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support This proposal > does not contains host mode, hence our customers concern. > What would be, in your opinion, the best policy that host control mode is > included in next Android LTS assuming it will be based on kernel v5.9 ? > > Thanks, > Avi Generally, the Android kernel team will accept backports of upstream patches. So just keep working on this and get it upstream as soon as you can, but it doesn't have to be 5.9. - Eric
Hi Avi, > -----Original Message----- > From: Avi Shchislowski <Avi.Shchislowski@wdc.com> > Sent: 16 July 2020 15:31 > To: Bart Van Assche <bvanassche@acm.org>; daejun7.park@samsung.com; Avri > Altman <Avri.Altman@wdc.com>; jejb@linux.ibm.com; > martin.petersen@oracle.com; asutoshd@codeaurora.org; > beanhuo@micron.com; stanley.chu@mediatek.com; cang@codeaurora.org; > tomas.winkler@intel.com; ALIM AKHTAR <alim.akhtar@samsung.com> > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Sang-yoon Oh > <sangyoon.oh@samsung.com>; Sung-Jun Park > <sungjun07.park@samsung.com>; yongmyung lee > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j-young.choi@samsung.com>; > Adel Choi <adel.choi@samsung.com>; BoRam Shin > <boram.shin@samsung.com> > Subject: RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > > > > -----Original Message----- > > From: Bart Van Assche <bvanassche@acm.org> > > Sent: Thursday, July 16, 2020 4:42 AM > > To: Avi Shchislowski <Avi.Shchislowski@wdc.com>; > > daejun7.park@samsung.com; Avri Altman <Avri.Altman@wdc.com>; > > jejb@linux.ibm.com; martin.petersen@oracle.com; > > asutoshd@codeaurora.org; beanhuo@micron.com; > stanley.chu@mediatek.com; > > cang@codeaurora.org; tomas.winkler@intel.com; ALIM AKHTAR > > <alim.akhtar@samsung.com> > > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; > > Sang-yoon Oh <sangyoon.oh@samsung.com>; Sung-Jun Park > > <sungjun07.park@samsung.com>; yongmyung lee > > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j- > young.choi@samsung.com>; > > Adel Choi <adel.choi@samsung.com>; BoRam Shin > <boram.shin@samsung.com> > > Subject: Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster > > Support > > > > CAUTION: This email originated from outside of Western Digital. Do not > > click on links or open attachments unless you recognize the sender and > > know that the content is safe. > > > > > > On 2020-07-15 11:34, Avi Shchislowski wrote: > > > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D > > > team > > in which Avri is a member of. > > > As the review process of HPB is progressing very constructively, we > > > are getting > > more and more requests from OEMs, Inquiring about HPB in general, and > > host control mode in particular. > > > > > > Their main concern is that HPB will make it to 5.9 merge window, but > > > the host > > control mode patches will not. > > > Thus, because of recent Google's GKI, the next Android LTS might not > > > include > > HPB with host control mode. > > > > > > Aside of those requests, initial host control mode testing are > > > showing > > promising prospective with respect of performance gain. > > > > > > What would be, in your opinion, the best policy that host control > > > mode is > > included in next Android LTS? > > > > Hi Avi, > > > > Are you perhaps referring to the HPB patch series that has already been > posted? > > Although I'm not sure of this, I think that the SCSI maintainer > > expects more > > Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken > > the time to review and/or test this patch series? > > > > Thanks, > > > > Bart. > > Yes, I am referring to the current proposal which I am replying to: > [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support This proposal > does not contains host mode, hence our customers concern. > What would be, in your opinion, the best policy that host control mode is > included in next Android LTS assuming it will be based on kernel v5.9 ? > This series has nothing to do with Host mode control, this series is targeted for device mode control. General consensus here is to land this series as it is (unless someone has more review comments) and lets add/enhance whatever need to be done for adding Host mode controls as well as other HPB2.0 related changes. > Thanks, > Avi
> > v5 -> v6 > > Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 > > > If no further comments, can this series have your Reviewed-by or Acked-by > tag, so that this can be taken for 5.9? > Thanks! Hey, yes. So sorry for this delay, I was away for few days. Yes - This series looks good to me. Thanks, Avri > > > v4 -> v5 > > Delete unused macro define. >
Hi Thanks to everyone for the clarifications Thanks, Avi > -----Original Message----- > From: Alim Akhtar <alim.akhtar@samsung.com> > Sent: Thursday, July 16, 2020 7:45 PM > To: Avi Shchislowski <Avi.Shchislowski@wdc.com>; 'Bart Van Assche' > <bvanassche@acm.org>; daejun7.park@samsung.com; Avri Altman > <Avri.Altman@wdc.com>; jejb@linux.ibm.com; martin.petersen@oracle.com; > asutoshd@codeaurora.org; beanhuo@micron.com; > stanley.chu@mediatek.com; cang@codeaurora.org; tomas.winkler@intel.com > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; 'Sang-yoon Oh' > <sangyoon.oh@samsung.com>; 'Sung-Jun Park' > <sungjun07.park@samsung.com>; 'yongmyung lee' > <ymhungry.lee@samsung.com>; 'Jinyoung CHOI' <j- > young.choi@samsung.com>; 'Adel Choi' <adel.choi@samsung.com>; 'BoRam > Shin' <boram.shin@samsung.com> > Subject: RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > CAUTION: This email originated from outside of Western Digital. Do not click on > links or open attachments unless you recognize the sender and know that the > content is safe. > > > Hi Avi, > > > -----Original Message----- > > From: Avi Shchislowski <Avi.Shchislowski@wdc.com> > > Sent: 16 July 2020 15:31 > > To: Bart Van Assche <bvanassche@acm.org>; daejun7.park@samsung.com; > > Avri Altman <Avri.Altman@wdc.com>; jejb@linux.ibm.com; > > martin.petersen@oracle.com; asutoshd@codeaurora.org; > > beanhuo@micron.com; stanley.chu@mediatek.com; cang@codeaurora.org; > > tomas.winkler@intel.com; ALIM AKHTAR <alim.akhtar@samsung.com> > > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; > > Sang-yoon Oh <sangyoon.oh@samsung.com>; Sung-Jun Park > > <sungjun07.park@samsung.com>; yongmyung lee > > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j- > young.choi@samsung.com>; > > Adel Choi <adel.choi@samsung.com>; BoRam Shin > <boram.shin@samsung.com> > > Subject: RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster > > Support > > > > > > > > > -----Original Message----- > > > From: Bart Van Assche <bvanassche@acm.org> > > > Sent: Thursday, July 16, 2020 4:42 AM > > > To: Avi Shchislowski <Avi.Shchislowski@wdc.com>; > > > daejun7.park@samsung.com; Avri Altman <Avri.Altman@wdc.com>; > > > jejb@linux.ibm.com; martin.petersen@oracle.com; > > > asutoshd@codeaurora.org; beanhuo@micron.com; > > stanley.chu@mediatek.com; > > > cang@codeaurora.org; tomas.winkler@intel.com; ALIM AKHTAR > > > <alim.akhtar@samsung.com> > > > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; > > > Sang-yoon Oh <sangyoon.oh@samsung.com>; Sung-Jun Park > > > <sungjun07.park@samsung.com>; yongmyung lee > > > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j- > > young.choi@samsung.com>; > > > Adel Choi <adel.choi@samsung.com>; BoRam Shin > > <boram.shin@samsung.com> > > > Subject: Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster > > > Support > > > > > > CAUTION: This email originated from outside of Western Digital. Do > > > not click on links or open attachments unless you recognize the > > > sender and know that the content is safe. > > > > > > > > > On 2020-07-15 11:34, Avi Shchislowski wrote: > > > > My name is Avi Shchislowski, I am managing the WDC's Linux Host > > > > R&D team > > > in which Avri is a member of. > > > > As the review process of HPB is progressing very constructively, > > > > we are getting > > > more and more requests from OEMs, Inquiring about HPB in general, > > > and host control mode in particular. > > > > > > > > Their main concern is that HPB will make it to 5.9 merge window, > > > > but the host > > > control mode patches will not. > > > > Thus, because of recent Google's GKI, the next Android LTS might > > > > not include > > > HPB with host control mode. > > > > > > > > Aside of those requests, initial host control mode testing are > > > > showing > > > promising prospective with respect of performance gain. > > > > > > > > What would be, in your opinion, the best policy that host control > > > > mode is > > > included in next Android LTS? > > > > > > Hi Avi, > > > > > > Are you perhaps referring to the HPB patch series that has already > > > been > > posted? > > > Although I'm not sure of this, I think that the SCSI maintainer > > > expects more > > > Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken > > > the time to review and/or test this patch series? > > > > > > Thanks, > > > > > > Bart. > > > > Yes, I am referring to the current proposal which I am replying to: > > [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support This > > proposal does not contains host mode, hence our customers concern. > > What would be, in your opinion, the best policy that host control mode > > is included in next Android LTS assuming it will be based on kernel v5.9 ? > > > This series has nothing to do with Host mode control, this series is targeted for > device mode control. General consensus here is to land this series as it is (unless > someone has more review comments) and lets add/enhance whatever need to > be done for adding Host mode controls as well as other HPB2.0 related changes. > > > Thanks, > > Avi
Martin - Can we move forward with this one? Thanks, Avri > > > > v5 -> v6 > > > Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 > > > > > If no further comments, can this series have your Reviewed-by or Acked-by > > tag, so that this can be taken for 5.9? > > Thanks! > Hey, yes. So sorry for this delay, I was away for few days. > Yes - This series looks good to me. > > Thanks, > Avri > > > > > > v4 -> v5 > > > Delete unused macro define. > >
Hi Martin > -----Original Message----- > From: Avri Altman <Avri.Altman@wdc.com> > Sent: 19 July 2020 12:05 > To: Alim Akhtar <alim.akhtar@samsung.com>; daejun7.park@samsung.com; > jejb@linux.ibm.com; martin.petersen@oracle.com; asutoshd@codeaurora.org; > beanhuo@micron.com; stanley.chu@mediatek.com; cang@codeaurora.org; > bvanassche@acm.org; tomas.winkler@intel.com > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; 'Sang-yoon Oh' > <sangyoon.oh@samsung.com>; 'Sung-Jun Park' > <sungjun07.park@samsung.com>; 'yongmyung lee' > <ymhungry.lee@samsung.com>; 'Jinyoung CHOI' <j- > young.choi@samsung.com>; 'Adel Choi' <adel.choi@samsung.com>; 'BoRam > Shin' <boram.shin@samsung.com> > Subject: RE: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > Martin - Can we move forward with this one? > > Thanks, > Avri > > > > > > > v5 -> v6 > > > > Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 > > > > > > > If no further comments, can this series have your Reviewed-by or > > > Acked-by tag, so that this can be taken for 5.9? > > > Thanks! > > Hey, yes. So sorry for this delay, I was away for few days. > > Yes - This series looks good to me. > > This series needs your attention. Thanks, > > Thanks, > > Avri > > > > > > > > > v4 -> v5 > > > > Delete unused macro define. > > >
Avri,
> Martin - Can we move forward with this one?
CHECK drivers/scsi/ufs/ufshcd-pltfrm.c
drivers/scsi/ufs/ufsfeature.c:90:20: warning: symbol 'ufshpb_dev_type' was not declared. Should it be static?
drivers/scsi/ufs/ufsfeature.c:104:17: warning: symbol 'ufsf_bus_type' was not declared. Should it be static?
CC [M] drivers/scsi/ufs/ufsfeature.o
CC [M] drivers/scsi/ufs/ufs_bsg.o
CC [M] drivers/scsi/ufs/ufs-sysfs.o
drivers/scsi/ufs/ufshpb.c:18:14: warning: symbol 'ufshpb_host_map_kbytes' was not declared. Should it be static?
drivers/scsi/ufs/ufshpb.c:793:28: warning: mixing different enum types:
drivers/scsi/ufs/ufshpb.c:793:28: unsigned int enum HPB_RGN_STATE
drivers/scsi/ufs/ufshpb.c:793:28: unsigned int enum HPB_SRGN_STATE
CC [M] drivers/scsi/ufs/ufshcd.o
drivers/scsi/ufs/ufshpb.c:1026:31: warning: context imbalance in 'ufshpb_run_active_subregion_list' - different lock contexts for basic block
> > Avri, > > > Martin - Can we move forward with this one? > > CHECK drivers/scsi/ufs/ufshcd-pltfrm.c > drivers/scsi/ufs/ufsfeature.c:90:20: warning: symbol 'ufshpb_dev_type' was > not declared. Should it be static? > drivers/scsi/ufs/ufsfeature.c:104:17: warning: symbol 'ufsf_bus_type' was not > declared. Should it be static? > CC [M] drivers/scsi/ufs/ufsfeature.o > CC [M] drivers/scsi/ufs/ufs_bsg.o > CC [M] drivers/scsi/ufs/ufs-sysfs.o > drivers/scsi/ufs/ufshpb.c:18:14: warning: symbol 'ufshpb_host_map_kbytes' > was not declared. Should it be static? > drivers/scsi/ufs/ufshpb.c:793:28: warning: mixing different enum types: > drivers/scsi/ufs/ufshpb.c:793:28: unsigned int enum HPB_RGN_STATE > drivers/scsi/ufs/ufshpb.c:793:28: unsigned int enum HPB_SRGN_STATE > CC [M] drivers/scsi/ufs/ufshcd.o > drivers/scsi/ufs/ufshpb.c:1026:31: warning: context imbalance in > 'ufshpb_run_active_subregion_list' - different lock contexts for basic block Martin - Thanks. Daejun - please run Sparse as well, not just checkpatch to eliminate those warnings. Thanks, Avri
As this monster seesm to come back again and again let me re-iterate
my statement:
I do not think Linux should support a broken standards extensions that
creates a huge share state between the Linux initator and the target
device like this with all its associated problems.
Nacked-by: Christoph Hellwig <hch@lst.de>
Christoph, > As this monster seesm to come back again and again let me re-iterate > my statement: > > I do not think Linux should support a broken standards extensions that > creates a huge share state between the Linux initator and the target > device like this with all its associated problems. I spent a couple of hours looking at this series again last night. And while the code has improved, I do remain concerned about the general concept. I understand how caching the FTL in host memory can improve performance from a theoretical perspective. However, I am not sure how much a difference this is going to make outside of synthetic benchmarks. What are the workloads that keep reading the same blocks from media? Or does the performance improvement exclusively come from the second order pre-fetching effect for larger I/Os? If so, why is the device's internal L2P SRAM cache ineffective at handling that case?
On 2020-07-22 06:27, Martin K. Petersen wrote: > Christoph Hellwig wrote: >> As this monster seems to come back again and again let me re-iterate >> my statement: >> >> I do not think Linux should support a broken standards extensions that >> creates a huge share state between the Linux initiator and the target >> device like this with all its associated problems. > > I spent a couple of hours looking at this series again last night. And > while the code has improved, I do remain concerned about the general > concept. > > I understand how caching the FTL in host memory can improve performance > from a theoretical perspective. However, I am not sure how much a > difference this is going to make outside of synthetic benchmarks. What > are the workloads that keep reading the same blocks from media? Or does > the performance improvement exclusively come from the second order > pre-fetching effect for larger I/Os? If so, why is the device's internal > L2P SRAM cache ineffective at handling that case? Hi Martin, These are great questions. The size of the L2P table is proportional to the device capacity and device capacities keep increasing. My understanding is that on-device SRAM is much more expensive than (host) DRAM. Caching the L2P table in host memory allows to keep the (UFS) device cost low. The Samsung HPB paper explains this as follows: "Mobile storage devices typically have RAM with constrained size, thus lack in memory to keep the whole mapping table." This is not an entirely new approach. The L2P table of the Fusion-io PCIe SSD adapters that were introduced more than ten years ago was entirely kept in host DRAM. The manual of that device documented how much memory the Fusion-io driver needed for the L2P table. This issue is not unique to UFS devices. My understanding is that DRAM cost is a significant part of the cost of enterprise and consumer SSD devices. SSD manufacturers are also interested in solutions to reduce the amount of DRAM inside SSDs. One possible solution, namely paging the L2P table, has a significant disadvantage, namely that it doubles the number of media accesses for random I/O with a small transfer size. The performance benefit of HPB comes from significantly reducing the number of media accesses in case of random I/O. I am not claiming that HPB is a perfect solution. But I wouldn't be surprised if enterprise SSD vendors would start looking into a similar solution sooner or later. Bart.
On Wed 2020-07-22 07:39:37, Christoph Hellwig wrote: > As this monster seesm to come back again and again let me re-iterate > my statement: > > I do not think Linux should support a broken standards extensions that > creates a huge share state between the Linux initator and the target > device like this with all its associated problems. > > Nacked-by: Christoph Hellwig <hch@lst.de> To be a bit more constructive. Yes, pushing (parts) of FTL to the host makes some kind of sense. IIRC lightnvm is a step into that direction. Pavel
On Thu, Jul 16, 2020 at 10:00:57AM +0000, Avi Shchislowski wrote: > > > > -----Original Message----- > > From: Bart Van Assche <bvanassche@acm.org> > > Sent: Thursday, July 16, 2020 4:42 AM > > To: Avi Shchislowski <Avi.Shchislowski@wdc.com>; > > daejun7.park@samsung.com; Avri Altman <Avri.Altman@wdc.com>; > > jejb@linux.ibm.com; martin.petersen@oracle.com; asutoshd@codeaurora.org; > > beanhuo@micron.com; stanley.chu@mediatek.com; cang@codeaurora.org; > > tomas.winkler@intel.com; ALIM AKHTAR <alim.akhtar@samsung.com> > > Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Sang-yoon Oh > > <sangyoon.oh@samsung.com>; Sung-Jun Park > > <sungjun07.park@samsung.com>; yongmyung lee > > <ymhungry.lee@samsung.com>; Jinyoung CHOI <j- > > young.choi@samsung.com>; Adel Choi <adel.choi@samsung.com>; BoRam > > Shin <boram.shin@samsung.com> > > Subject: Re: [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support > > > > CAUTION: This email originated from outside of Western Digital. Do not click on > > links or open attachments unless you recognize the sender and know that the > > content is safe. > > > > > > On 2020-07-15 11:34, Avi Shchislowski wrote: > > > My name is Avi Shchislowski, I am managing the WDC's Linux Host R&D team > > in which Avri is a member of. > > > As the review process of HPB is progressing very constructively, we are getting > > more and more requests from OEMs, Inquiring about HPB in general, and host > > control mode in particular. > > > > > > Their main concern is that HPB will make it to 5.9 merge window, but the host > > control mode patches will not. > > > Thus, because of recent Google's GKI, the next Android LTS might not include > > HPB with host control mode. > > > > > > Aside of those requests, initial host control mode testing are showing > > promising prospective with respect of performance gain. > > > > > > What would be, in your opinion, the best policy that host control mode is > > included in next Android LTS? > > > > Hi Avi, > > > > Are you perhaps referring to the HPB patch series that has already been posted? > > Although I'm not sure of this, I think that the SCSI maintainer expects more > > Reviewed-by: and Tested-by: tags. Has anyone from WDC already taken the > > time to review and/or test this patch series? > > > > Thanks, > > > > Bart. > > Yes, I am referring to the current proposal which I am replying to: > [PATCH v6 0/5] scsi: ufs: Add Host Performance Booster Support This proposal does not contains host mode, hence our customers concern. > What would be, in your opinion, the best policy that host control mode is included in next Android LTS assuming it will be based on kernel v5.9 ? To come back to this statement, as I keep seeing it in odd places... I have never said that the next LTS kernel would be 5.9, where did you get that from? I am pretty sure that Google is also not saying that either. Work to get the feature accepted properly, do not worry about cramming anything into any kernel just because it might be a LTS release. That causes problems that we have had in the past, and one would hope that we would have learned from our mistakes. thanks, greg k-h