From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 517AF29D260 for ; Wed, 22 Jul 2026 12:59:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784725176; cv=none; b=SWVe21+hH8Yo21Y7oOJcgr+MdKojrHJ5+OigdoiKCXypEIB+SnJdswZIFx4DZCyHfvn1GyWjQGrU3v1BtLJU6+WQ9wc28BlqVLlvHu1Cy1SFHdRqNTCBKkXdHdCE2utiY2IKkrcVhSSI31LmpuIPh7mqmb4r4liz/3ew37d0C4Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784725176; c=relaxed/simple; bh=M1GFHM4Oi9fRIMIxEuEGRx/HKeIHW+a4Qmbhw0qaXS8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Yrc9st7QpCH9Adq3Cq+EF0L+3/OsjtlIIpCYtPGXj7YsTk3mGRJSQFsP13CaCN3cHFE+9s+5wD+v/TB47qsMm6JdH59eiGi3tZvgnysX5cOFtrVh/b58BTbLZXLyQN5jeC1J+r+qgIsBwjBmKm8d7cetfq7I5eZWr0fYgFS77Tk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HHkqNA+S; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HHkqNA+S" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DF531F000E9; Wed, 22 Jul 2026 12:59:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784725175; bh=icrLLQhuAoMMBcn0S+gJv4GWVoPCUHqQS5tuhEzj+P8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HHkqNA+SdSANlLAg1mmyPZ1gEYvTdBupa85eW5aZvlbHeIN/8ANEb6JE8o83tIARz 0upwQFZ5qROTS6MK88OcnqPU5dQtXOELCUo1Et2thYWG4kDmO6P+3vfltzASbe4e1n Uq2iA6WwBrUan8Z9HNvB3TdtPrf5a/zd11Sh5z8/IlHvcO8MxkAnNSksVLv1OEh4h4 vTvImCvgtntXUIxH6Y8PUQK/VyraFgkS3d8p7hnpZJe5AIFzzz8fOhU1QJAIEQWJV3 yRt+Z8JMgX/9hPjywyKAxIJ0ICeqMR0hkUbdQ2V0YblkMR0gOyLzLpCaoPxdhYBXJ9 IbIWkpCZJU7kA== Date: Wed, 22 Jul 2026 13:59:19 +0100 From: "Lorenzo Stoakes (ARM)" To: Wandun Chen 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 Message-ID: References: <20260722125133.543441-1-chenwandun1@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > > 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 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 >