lkml.org 
[lkml]   [2020]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver
    From
    Date
    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
    > >
    >
    >

    \
     
     \ /
      Last update: 2020-04-30 14:46    [W:5.022 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site