On Mon, Feb 01, 2021 at 08:17:59AM +0000, Avri Altman wrote:

quoted

On Mon, Feb 01, 2021 at 07:51:19AM +0000, Avri Altman wrote:

quoted

quoted

On Mon, Feb 01, 2021 at 07:12:53AM +0000, Avri Altman wrote:

quoted

quoted

quoted

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

quoted

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.

quoted

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.

So how do you solve it?  And how would you expect a user to solve it if
the kernel can not?

You better document the heck out of these configuration options :)

thanks,

greg k-h