Hello, All!
I write this email that is my opinion regard to HPB.
This mail is very long. So, summary is ... :
[Summary]
1. HPB, Write Booster and other new UFS features would
be managed by ufs-extended feature layer (additional LLD layer)
2. Map table of HPB will be managed in LLD (UFS Driver)
3. Each ufs feature driver can be implemented as a loadable kernel module
4. Samsung prepares test environment based on QEMU also
5. We will push our patch as soon! Please review this.
This is body:
I am Yongmyung Lee, who is one of the original authors of the HPB driver,
which was out-of-tree implementation from linux kernel mainline.
I have seen the works done by Bean Hou and Avri Altman, which are very impressive.
I also have some opinion on the driver
and would like to consult with you about it and prepare a set of patches.
The basic idea of my approach is similar to Bean's work
of managing HPB map-data in LLD (UFS Driver).
As HPB Driver is closely related to the behavior of the
UFS Device, I think it would be nice if HPB Driver runs on the LLD layer.
HPB Driver is closely related to the behavior of the UFS Device.
Thus I think it would be nice if HPB Driver works on additional feature layer on LLD.
Of course, Avri's work makes sense.
I believe HPB's scheme can be a good alternative to HMB(Host Memory Buffer)of NVMe
for storage devices like eMMC or SATA SSD (may be DRAMless).
Once HPB-like scheme is applied,
these storage devices could benefit from performance improvement
in read latency as well as throughput.
However, it would not be desirable to relocate
the map table management to the upper layer such as scsi-dh
as there are no such specification supported for the moment.
When the similar specifications to HPB will be proposed in JEDEC or T13,
it would be a great chance to have a deep discussion on
which layer to be the best fit for the map table management.
Before disclosing my opinion on the HPB driver development approach,
I would like to introduce the main characteristics of Extended UFS-Feature in progress:
* Providing extended functionality.
That is, UFS device shall work well without extended UFS-Features.
By using them, however, it will be more powerful in certain application scenarios.
* Designed to suit the Embedded system (such as Android)
Due to the characteristics of UFS device,
it is being utilized mainly as a mobile storage.
We are mainly trying to improve performance in Android system.
* Closely connected to the UFS devices.
The Extended UFS-Features use UFS query requests
which are UFS private commands.
In addition, other features are closely related with
electrical and physical characteristics of UFS
(such as Voltage, Gear-scaling and Runtime suspend/resume etc.,)
and should be taken into consideration
Therefore, it is desirable to have those features managed
separately from the original UFS driver.
Current extended UFS-Features which are approved by the JEDEC are as below:
* UFS HPB
* UFS WriteBooster
In addition to that, we are developing and testing various UFS-features
that would be beneficial in the Embedded system
(At the moment, most of them would be Android system).
As we have already successfully provided enhanced features
in cooperation with major Android Phone vendors,
now we willingly want to contribute our works to the Linux kernel mainline.
Currently, UFS driver (usually ufshcd.c) has become bulky and complex.
So, I would like to split these codes into layers
like the works of Bean Huo and Avril Altman.
Especially, I suggest the UFS-Feature Driver model based on Linux Bus-Driver Model,
which is suitable to manage all Extended UFS-Feature drivers like the Figure as below:
UFS Driver data structure (struct ufs_hba)
|
| ----------------------- -- ufshpb driver -- <- attach ufshpb device driver (it can be loadable)
|---| ufs-ext feature layer | -- ufs-wb driver -- <- attach ufswb device driver
| | | -- ... -- <- ...
| ----------------------- -- next ufs feature driver -- <- attach ufs-next feature driver
* wb : write-booster
Each extended UFS-Feature Driver has a bus of ufs-ext feature type
and it is bound to the ufs-ext feature layer.
The ufs-ext feature layer manages common APIs used by each Extended UFS-Feature Driver.
The APIs consist of UFS Query request and
UFS Vendor commands related to each ufs-ext feature driver.
Furthermore, each ufs-ext feature driver will be written as a loadable kernel module.
Vendors (e.g., Android Phone manufacturer) could optionally load and remove each module.
Also they can customize the parameters of ufs-ext feature drivers
while each module is being loaded.
(For example, vendor would set the maximum memory size
that can be reclaimed in the Host Control mode in HPB)
We are expecting that this kind of standardized and
abstracted model will surely make it easier to manage the ufs-ext feature drivers.
I noticed that the ufs-wb (write-booster) patch was written by Asutosh Das and Stanley Chu.
The basic idea of ufs-wb code is to proceed write boosting
in adjusting gear-scaling, which is a good idea that I did not think of.
I also would like to incorporate ufs-wb driver into the ufs-ext feature layer,
and in this way the footprint of UFS driver could be slimmed down likewise.
In brief, system vendors can optimize their system
by loading each ufs-ext feature driver selectively.
As of now I am still working on the patch and
have it tested on the android phone with real UFS-HPB device on the stable androidzed kernel
as well as on a ufs-simulator based on QEMU to reflect latest kernel version with my team members.
In addition, we plan to provide QEMU with UFS-simulator
for a test environment for UFS driver development.
I hope there will be a lot of comments on my idea
and patch set to be pushed in the near future
and I will willingly reflect every single opinion.
I will push up my patch set as soon as possible.
Thank you
