On Fri, Sep 12, 2025 at 04:35:44PM +0100, Pedro Falcato wrote:

On Fri, Sep 12, 2025 at 03:01:02PM +0100, Lorenzo Stoakes wrote:

quoted

Yes, but at least an eagerness parameter gets us closer to this ideal.

Of course, I agree that max_ptes_none should simply never have been exposed like
this. It is emblematic of a 'just shove a parameter into a tunable/sysfs and let
the user decide' approach you see in the kernel sometimes.

This is problmeatic as users have no earthly idea how to set the parameter (most
likely never touch it), and only start fiddling should issues arise and it looks
like a viable solution of some kind.

The problem is users usually lack a great deal of context the kernel has, and
may make incorrect decisions that work in one situation but not another.

Note that in this case we really don't have much for context. We can trivially do
"check what number of ptes are mapped", but not anything much fancier. You can

I mean we could in theory change where we determine things, for instance doing
things in reclaim as Kiryl alluded to.

We _potentially_ have more to work with.

The good news is that there are 3 or 4 separate movements for getting page
"temperature" information with their own special infra and daemons, for their
own special little features.

Right.

quoted

TL;DR - this kind of interface is just lazy and we have to assess these kinds of
tunables based on the actual RoI + understanding from the user's perspective.

Fully agreed.

--
Pedro

My overall point, FWIW, is that a synthetic heuristic tunable works better here
than one that maps on to an internal value that we then have no control over.

Or 'I agree with David' IOW :)

Cheers, Lorenzo