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
