linux-kernel - Re: Another approach of UFSHPB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <231786897.01590570902533.JavaMail.epsvc@epcpadp1>
Date:   Wed, 27 May 2020 18:11:06 +0900
From:   Daejun Park <daejun7.park@...sung.com>
To:     Bart Van Assche <bvanassche@....org>,
        Avri Altman <Avri.Altman@....com>,
        Daejun Park <daejun7.park@...sung.com>,
        yongmyung lee <ymhungry.lee@...sung.com>,
        "James E . J . Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     ALIM AKHTAR <alim.akhtar@...sung.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        Zang Leigang <zangleigang@...ilicon.com>,
        Avi Shchislowski <Avi.Shchislowski@....com>,
        Bean Huo <beanhuo@...ron.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        MOHAMMED RAFIQ KAMAL BASHA <md.rafiq@...sung.com>,
        Sang-yoon Oh <sangyoon.oh@...sung.com>,
        Jinyoung CHOI <j-young.choi@...sung.com>,
        Adel Choi <adel.choi@...sung.com>,
        BoRam Shin <boram.shin@...sung.com>,
        Sung-Jun Park <sungjun07.park@...sung.com>
Subject: Re: Another approach of UFSHPB

On 2020-05-26 Bart Van Assche wrote:
>On 2020-05-25 23:15, Avri Altman wrote:
>>> On 2020-05-24 22:40, Daejun Park wrote:
>>>> The HPB driver is close to the UFS core function, but it is not essential
>>>> for operating UFS device. With reference to this article
>>>> (https://lwn.net/Articles/645810/), we implemented extended UFS-feature
>>>> as bus model. Because the HPB driver consumes the user's main memory, it
>>> should
>>>> support bind / unbind functionality as needed. We implemented the HPB
>>> driver
>>>> can be unbind / unload on runtime.
>>>
>>> I do not agree that the bus model is the best choice for freeing cache
>>> memory if it is no longer needed. A shrinker is probably a much better
>>> choice because the callback functions in a shrinker get invoked when a
>>> system is under memory pressure. See also register_shrinker(),
>>> unregister_shrinker() and struct shrinker in include/linux/shrinker.h.
>>
>> Since this discussion is closely related to cache allocation,
>> What is your opinion about allocating the pages dynamically as the regions
>> Are being activated/deactivated, in oppose of how it is done today - 
>> Statically on init for the entire max-active-subregions?

> Memory that is statically allocated cannot be used for any other purpose
> (e.g. page cache) without triggering the associated shrinker. As far as
> I know shrinkers are only triggered when (close to) out of memory. So
> dynamically allocating memory as needed is probably a better strategy
> than statically allocating the entire region at initialization time.

To improve UFS device performance using the HPB driver, 
the number of active-subregions above a certain threshold is essential.
If the number of active-subregions is lower than the threshold, 
the performance improvement by using HPB will be reduced. 
Also, due to frequent and active/inactive protocol overhead, 
performance may be worse than when the HPB feature is not used.

Therefore, it is better to unbind/unload HPB driver than 
to reduce the number of active subregions below the threshold. 
We designed the HPB driver to make the UFS device work 
even when the module is unloaded.

Thanks,

Daejun