Hi, I appreciate your insightful comments. > we propose --> jedec spec XXX proposes … > 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 shared by several features. > There are up to now 10 extended features defined, but none of them can share a common api. > What other features can share this additional layer? And how those ops can 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 for checking lifetime of UFS. > This 2017 study, is being cited by everyone, but does not really describes 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 figures? There are no other public studies currently. However, when using HPB, there is an internal report that read latency is improved in android user-case scenarios, as well as in the benchmarks. Thanks, Daejun
