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] [day] [month] [year] [list]

Message-ID: <f6e600794bd80d9bcbf91863f91170183723cc75.camel@gmail.com>
Date:   Wed, 27 May 2020 13:46:50 +0200
From:   Bean Huo <huobean@...il.com>
To:     daejun7.park@...sung.com, Bart Van Assche <bvanassche@....org>,
        Avri Altman <Avri.Altman@....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 Wed, 2020-05-27 at 18:11 +0900, Daejun Park wrote:
> > > > 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.

Right, but for the embedded system, it is different to mobile usage
case, there should be a maximum limit in the HPB driver, exactly
how much MB of HPB cache, should let the user choose.


> 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.
>

Actually, along with the HPB running, from point of the HPB cache
consumption, no big difference between dynamical HPB page allocation
and statical allocation. on the contrary, dynamically HPB page
allocation will increase the latency in the HPB entries loading path.

//Bean