Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Mime-Version: 1.0
Subject: RE: RE: [RFC PATCH 0/5] scsi: ufs: Add Host Performance Booster
 Support
Reply-To: daejun7.park@samsung.com
From:   Daejun Park <daejun7.park@samsung.com>
To:     Avri Altman <Avri.Altman@wdc.com>,
        Daejun Park <daejun7.park@samsung.com>,
        ALIM AKHTAR <alim.akhtar@samsung.com>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "beanhuo@micron.com" <beanhuo@micron.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "tomas.winkler@intel.com" <tomas.winkler@intel.com>
CC:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@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>
In-Reply-To: <SN6PR04MB4640DC01229F2073C2BD3103FC870@SN6PR04MB4640.namprd04.prod.outlook.com>
Message-ID: <336371513.41591664282662.JavaMail.epsvc@epcpadp2>
Date:   Tue, 09 Jun 2020 09:49:34 +0900
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
References: <SN6PR04MB4640DC01229F2073C2BD3103FC870@SN6PR04MB4640.namprd04.prod.outlook.com>
        <231786897.01591320001492.JavaMail.epsvc@epcpadp1>
        <CGME20200605011604epcms2p8bec8ef6682583d7248dc7d9dc1bfc882@epcms2p4>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

I appreciate your insightful comments.
 =20
> we propose  --> jedec spec XXX proposes =E2=80=A6
> and here you also disclose what version of the spec are you supporting
I will change to "JESD220-3 (HPB v1.0) proposes".
This patch supports HPB version 1.0.

> Like Bart, I am not sure that this extra module is needed.
> It only makes sense if indeed there are some common calls that can be sha=
red by several features.
> There are up to now 10 extended features defined, but none of them can sh=
are a common api.
> What other features can share this additional layer?  And how those ops c=
an be reused?
> If you have some future implementations in mind, you should add this api =
once you'll add those.
We added UFS feature layer with several callbacks to important parts of the=
 UFS control flow.
Other extended features can also be implemented using the proposed APIs.
For example, in WB, "prep_fn" can be used to guarantee the lifetime of UFS =
by updating the amount of write IO used as WB.
And reset/reset_host/suspend/resume can be used to manage the kernel task f=
or checking lifetime of UFS.

> This 2017 study, is being cited by everyone, but does not really describe=
s it's test setup to its details.
> It  does say however that they used a 16MB subregions over a range of 1GB=
,
> which can be covered by a 64 active regions, Even for a single subregion =
per region.
> Meaning no eviction should take place, thus HPB overhead is minimized.
> Do we have a more recent public studies that supports those impressive fi=
gures?
There are no other public studies currently.
However, when using HPB, there is an internal report that read latency is i=
mproved in android=20
user-case scenarios, as well as in the benchmarks.

Thanks,
Daejun