> > On Mon, Feb 01, 2021 at 07:51:19AM +0000, Avri Altman wrote: > > > > > > On Mon, Feb 01, 2021 at 07:12:53AM +0000, Avri Altman wrote: > > > > > > +#define WORK_PENDING 0 > > > > > > +#define ACTIVATION_THRSHLD 4 /* 4 IOs */ > > > > > Rather than fixing it with macro, how about using sysfs and make it > > > > > configurable? > > > > Yes. > > > > I will add a patch making all the logic configurable. > > > > As all those are hpb-related parameters, I think module parameters are > > > more adequate. > > > > > > No, this is not the 1990's, please never add new module parameters to > > > drivers. If not for the basic problem of they do not work on a > > > per-device basis, but on a per-driver basis, which is what you almost > > > never want. > > OK. > > > > > > > > But why would you want to change this value, why can't the driver "just > > > work" and not need manual intervention? > > It is. > > But those are a knobs each vendor may want to tweak, > > So it'll be optimized with its internal device's implementation. > > > > Tweaking the parameters, as well as the entire logic, is really an endless > task. > > Some logic works better for some scenarios, while falling behind on others. > > Shouldn't the hardware know how to handle this dynamically? If not, how > is a user going to know? There is one "brain". It is either in the device - in device mode, Or in the host - in host mode control. The "brain" decides which region is active, thus carrying the physical address along with the logical - minimizing context switches in the device's RAM. There can be up to N active regions. Activation and deactivation has its overhead. So basically it is a constraint-optimization problem. > > > How about leaving it for now, to be elaborated it in the future? > > I do not care, just do not make it a module parameter for the reason > that does not work on a per-device basis. OK. Will make it a sysfs per hpb-lun, like Daejun proposed. Thanks, Avri
