Re: [DISCUSSION] proposed mctl() API

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:

quoted

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_?