linux-kernel - Re: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver

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]

Date:   Thu, 30 Apr 2020 14:45:40 +0200
From:   Bean Huo <huobean@...il.com>
To:     Avri Altman <Avri.Altman@....com>,
        Bart Van Assche <bvanassche@....org>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>
Cc:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB)
 driver

On Thu, 2020-04-30 at 07:23 +0000, Avri Altman wrote:
> Hi Bean,
> 
> > > By now we've read the device HPB configuration, and we are
> > > ready  to
> > > attach a scsi device to our HPB luns.  A perfect timing might be
> > > while
> > > scsi is performing its .slave_alloc() or .slave_configure().
> > > 
> > 
> > hi, Avri
> > That means HPB memory allocation done in .scan_finished() ?
> 
> The specifics of this feature are yet to be determined.
> 
> Among those, yes - we need to discuss how to handle the memory
> allocation.
> Statically allocating the required cache for the entire max-active-
> subregions,
> Which may sum-up to a hundreds of MB, has its obvious downsize. 
> We need to discuss this further.
> 
> > and sd_init_command() needs to change as well, add a new request
> > type REQ_OP_HPB_READ?
> 
> Again, this is an implementation issue.
> We need to figure it out in the sequel.
> E.g. we might want to make use of the combination of a valid handler
> and blk_op_is_private.
> 
> I think it would be more constructive, if we can decide first on the
> module layout,
> And figure out the other details as we go?
> 
> Can you provide the pros and cons for the Samsung approach -
> implementing all HPB functionalities using a single LLD?
> 
> Thanks,
> Avri
> 
Hi Avri

Samsung approach is a flat design and the HPB functions are embedded in
the UFSHBA driver, looks ugly.  Each LU has its own HPB cache, which
statically allocated in HPB initialization stage.  If one LU runs out
of its HPB cache, it is impossbile to borrow HPB cache from its
neighbour LU. Also, HPB requests are enqueued to the scsi_device
request_queue and then fly back to SCSI layer. This unavoidably
lengthens the latency of HPB entry update. 
For the HPB host control mode, the predictability of HPB region
activation of this design is lower, since HPB driver doesn't know which
Region exactly should be activated in advance.

Regarding its pros, exactly I don't know, maybe it is relatively
simple, work, and there are already customers who are using it now.
also, we don't need to argue with SCSI layers and maintenance is
easier.

To me, hierarchical design sounds good, and move the implementation of
HPB manager module to SCSI layer is nice. but what is opinion of
others? and which way they prefer. or they want us to continue current
Samsung approach and solve its cons further.

thanks,

Bean

> > 
> > 
> > Bean
> > 
> 
>