[lkml]   [2020]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Another approach of UFSHPB
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
> (, 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.

>> Should these parameters be per module or per UFS device?
> I think it is necessary to take parameters for each module.
> This is because each extended UFS-feature module has different functions
> and may require different parameters.

My question was a rhetorical question. Please choose per device
parameters when appropriate instead of module parameters.



 \ /
  Last update: 2020-05-25 16:57    [W:0.103 / U:3.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site