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: > > 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. > > > > > 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
