On Thu, May 29, 2025 at 04:28:46PM +0100, Matthew Wilcox wrote: > On Thu, May 29, 2025 at 03:43:26PM +0100, Lorenzo Stoakes wrote: > > After discussions in various threads (Usama's series adding a new prctl() > > in [0], and a proposal to adapt process_madvise() to do the same - > > conception in [1] and RFC in [2]), it seems fairly clear that it would make > > sense to explore a dedicated API to explicitly allow for actions which > > affect the virtual address space as a whole. > > > > Also, Barry is implementing a feature (currently under RFC) which could > > additionally make use of this API (see [3]). > > I think the reason that you're having trouble coming up with a good > place to put these ideas is because they are all bad ideas. Do none of > them. Problem solved. > > People should put more effort into allocating THPs automatically and > monitoring where they're helping performance and where they're hurting > performance, instead of coming up with these baroque reasons to blame > the sysadmin for not having tweaked some magic knob. > > Barry's problem is that we're all nervous about possibly regressing > performance on some unknown workloads. Just try Barry's proposal, see > if anyone actually compains or if we're just afraid of our own shadows. > So from my perspective - I very much agree with the concept of doing nothing here, ideally :) But I feel we need to look at this problem from both the short term and the long term - in the long run I absolutely agree with what you say. In the short term this proposal is broadly 'what is the least worst means of establishing policy like this?'. I think there is broad agreement that prctl() is sub-optimal, so an mm-specific API makes sense. So it comes down to a question of - how badly do we need to be able to do this _now_?
