Hey Miklos

On Fri, 18 Jun 2021 at 16:42, Miklos Szeredi [off-list ref] wrote:

On Fri, 18 Jun 2021 at 10:31, Michael Stapelberg
[off-list ref] wrote:

quoted

Maybe, but I don’t have the expertise, motivation or time to
investigate this any further, let alone commit to get it done.
During our previous discussion I got the impression that nobody else
had any cycles for this either:
https://lore.kernel.org/linux-fsdevel/CANnVG6n=ySfe1gOr=0ituQidp56idGARDKHzP0hv=ERedeMrMA@mail.gmail.com/ (local)

Have you had a look at the China LSF report at
http://bardofschool.blogspot.com/2011/?
The author of the heuristic has spent significant effort and time
coming up with what we currently have in the kernel:

"""
Fengguang said he draw more than 10K performance graphs and read even
more in the past year.
"""

This implies that making changes to the heuristic will not be a quick fix.

Having a piece of kernel code sitting there that nobody is willing to
fix is certainly not a great situation to be in.

Agreed.

And introducing band aids is not going improve the above situation,
more likely it will prolong it even further.

Sounds like “Perfect is the enemy of good” to me: you’re looking for a
perfect hypothetical solution,
whereas we have a known-working low risk fix for a real problem.

Could we find a solution where medium-/long-term, the code in question
is improved,
perhaps via a Summer Of Code project or similar community efforts,
but until then, we apply the patch at hand?

As I mentioned, I think adding min/max limits can be useful regardless
of how the heuristic itself changes.

If that turns out to be incorrect or undesired, we can still turn the
knobs into a no-op, if removal isn’t an option.

Thanks
Best regards
Michael