All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Wandun Chen <chenwandun1@gmail.com>
Cc: liam@infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,  akpm@linux-foundation.org,
	vbabka@kernel.org, jannh@google.com, pfalcato@suse.de
Subject: Re: [PATCH] mm/mlock: skip __mm_populate() for MLOCK_ONFAULT
Date: Wed, 22 Jul 2026 13:59:19 +0100	[thread overview]
Message-ID: <amC9AO3YoSnKewkp@lucifer> (raw)
In-Reply-To: <20260722125133.543441-1-chenwandun1@gmail.com>

On Wed, Jul 22, 2026 at 08:51:33PM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> MLOCK_ONFAULT only locks pages on future faults, so there is no need to
> fault in non-present pages during the mlock2/mlockall syscall.
> populate_vma_page_range() already returns immediately for VMAs with
> VM_LOCKONFAULT, which means __mm_populate() just loops over VMAs and
> holds mmap_read_lock without doing useful work.
>
> Skip __mm_populate() when MLOCK_ONFAULT is set to avoid this unnecessary
> work.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>

Well you take mmap read lock and release it (after having held the write lock),
hardly earth-shattering.

And this has been this way for donkey's years I don't really see why we should
care?

Do you have a workload that's heavily dependent on mlock2(..., MLOCK_ONFAULT) or
mlockall(..., MCL_ONFAULT) as a hot path that is seriously contending the mmap
lock?

I don't love how the VMA_LOCKONFAULT_BIT flag works but I'm not sure adding more
churn and code for the sake of it here is really worth it.

Thanks, Lorenzo

> ---
>  mm/mlock.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/mm/mlock.c b/mm/mlock.c
> index efa6716e4dfb..784bd4bfc3bb 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -658,9 +658,11 @@ static __must_check int do_mlock(unsigned long start, size_t len,
>  	if (error)
>  		return error;
>
> -	error = __mm_populate(start, len, 0);
> -	if (error)
> -		return __mlock_posix_error_return(error);
> +	if (!vma_flags_test(flags, VMA_LOCKONFAULT_BIT)) {
> +		error = __mm_populate(start, len, 0);
> +		if (error)
> +			return __mlock_posix_error_return(error);
> +	}
>  	return 0;
>  }
>
> @@ -778,7 +780,7 @@ SYSCALL_DEFINE1(mlockall, int, flags)
>  	    capable(CAP_IPC_LOCK))
>  		ret = apply_mlockall_flags(flags);
>  	mmap_write_unlock(current->mm);
> -	if (!ret && (flags & MCL_CURRENT))
> +	if (!ret && (flags & MCL_CURRENT) && !(flags & MCL_ONFAULT))
>  		mm_populate(0, TASK_SIZE);
>
>  	return ret;
> --
> 2.43.0
>


      reply	other threads:[~2026-07-22 12:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 12:51 [PATCH] mm/mlock: skip __mm_populate() for MLOCK_ONFAULT Wandun Chen
2026-07-22 12:59 ` Lorenzo Stoakes (ARM) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amC9AO3YoSnKewkp@lucifer \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chenwandun1@gmail.com \
    --cc=jannh@google.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pfalcato@suse.de \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.