From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CF6B72EBBA4 for ; Thu, 9 Apr 2026 18:47:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775760458; cv=none; b=qosOTiTWSqahWr+YTbwBpvp3aDi28VYninYLY+l5blOZkeYTkb+e07gSLwd4RWerVZBSf+gtJGbe98SE3CylM3/0d7+XFapBkGFsn17Keibt2sH+prXU+M0pGr3cYLmcH4uepFnTRAHDMnULXqXxxuUIzdEdYe0PfSqLkksSOmM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775760458; c=relaxed/simple; bh=9hyJHbfFEUwXp5G3u37Z51sC8+W3u2u16Ri8A5G5bWc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jd2Ejb6ix2zD83HGIoKkyGu+tW7KEOaBuAfCVX+4BWAEMBgxqx6z0WmO4/7L34B3tLLL5L+vnLmnrGqKG2mJwuz6IE952gqBmn0KrvixGsdCsgS1SRg8D5ka7jfvZiHq0woxAvdR7Sta1wXyd+w3w+C5z47U13IV+IHWzDTb+5A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tdxt77ps; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tdxt77ps" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1735DC4CEF7; Thu, 9 Apr 2026 18:47:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775760458; bh=9hyJHbfFEUwXp5G3u37Z51sC8+W3u2u16Ri8A5G5bWc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tdxt77psaSManp8RwTtMljaONd8XKkvy+BI0xBuX8TWyQrhWmgmSLlhsKOXcaFt6g 0X/KUwJw/psdQ+OVJML4OZct+J7Ja/rHBkJkyBsQW0Z9Q/dtRUcDlSP0Ii4IcYWy8D oyknISWY8cuoYmXGMnA8wn6qP4gBNR4db//fXZsQP1BoaNjEq09V07gtKf0iTqLeXo DODHhOKA5l8VZZX3jVNEYuWlc21fPJEV1RXZ7RZmI5iYCVDw97lFMWkcOjvsZ9GM3H xDc5SRaKVtb3iSHWF4swYaijPGVrYjPdj8B04VRnGVgidqN1X5QETOFrx11507JGkB BIyIeC7qeTgRQ== Date: Thu, 9 Apr 2026 19:47:31 +0100 From: Lorenzo Stoakes To: John Hubbard Cc: Hugh Dickins , Joseph Salisbury , Andrew Morton , David Hildenbrand , Chris Li , Kairui Song , Jason Gunthorpe , Peter Xu , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , linux-mm@kvack.org, LKML Subject: Re: [RFC] mm: stress-ng --mremap triggers severe lruvec lock contention in populate/unmap paths Message-ID: References: <4a4f5b48-8a1d-48f8-8760-0f5d43b5d483@nvidia.com> <982e5964-5ea6-eaf7-a11a-0692f14a6943@google.com> <2cec5f0a-93cc-4572-9793-17f9fd123d2c@nvidia.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: <2cec5f0a-93cc-4572-9793-17f9fd123d2c@nvidia.com> On Thu, Apr 09, 2026 at 11:12:39AM -0700, John Hubbard wrote: > > ... > >>> + * Read VM_LOCKED before __get_user_pages(), which may drop > >>> + * mmap_lock when FOLL_UNLOCKABLE is set, after which the vma > >>> + * must not be accessed. The read is stable: mmap_lock is held > >>> + * for read here, so mlock() (which needs the write lock) > >>> + * cannot change VM_LOCKED concurrently. > >>> + */ > > > > BTW, not to nitpick (OK, maybe to nitpick :) this comments feels a bit > > redundant. Maybe useful to note that the lock might be dropped (but you don't > > indicate why it's OK to still assume state about the VMA), and it's a known > > thing that you need a VMA write lock to alter flags, if we had to comment this > > each time mm would be mostly comments :) > > > > So if you want a comment here I'd say something like 'the lock might be dropped > > due to FOLL_UNLOCKABLE, but that's ok, we would simply end up doing a redundant > > drain in this case'. > > > > But I'm not sure it's needed? > > I'm OK with just dropping the whole comment. I've lost my way lately with > comment density. :) Thanks, yeah I get this wrong myself often - I think tending towards more comments is the better default :) > > > > >>> + need_drain = vma->vm_flags & VM_LOCKED; > > > > Please use the new VMA flag interface :) > > Oops, yes. It's entirely forgiveable because this is massively new and pretty much nobody but me and people who've bumped into it on review are all that aware :P I mean I'll end up converting it all later anyway. > > I'm on the fence about whether to post an updated version of this. > Maybe wait until someone pops up with a real need for it? > > Thoughts? Yeah, let's wait for a real world case, otherwise we'll never be sure that we're not solving the wrong problem I think. > > thanks, > -- > John Hubbard > Cheers, Lorenzo