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 A104B279DCE
	for <linux-kernel@vger.kernel.org>; Fri, 21 Nov 2025 19:52:04 +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=1763754724; cv=none; b=bXc7TFiXQGr2gK9ifuXNtAAg1bUDdDU38I/hV+gnS07CZyPoP/fkd9EXtS4SwpPZ4uUZA9Q98IrIaAg3aia68SvLI990OgvpKXhK7jocsu0cbON34HLDuvK0sSTVPZxXfCvt6QgOKFz5Cqjk7hk9/T6v7UiXuYszWRJX8acwaDM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1763754724; c=relaxed/simple;
	bh=xfWX1MWedHrZ+OmxiBiUepfssMh2KX6vp847cJtltI0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=pVMnGgnVvUohGH+PmErRouw+FysXcF2SLq6xEInOQVu5/RYUXVqrJBI99TQLH9Q9bRLVIRbcObq9gSPwNnAgiZBPJbJ7vjo+65vnOf/VBRLqsKIN54qHtZHxolzaT3OOWNFpVlwizXLwsS2SimU5jZ/xROXbJx8dT1r0tPz8WtA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aubBZ50K; 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="aubBZ50K"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6357C4CEF1;
	Fri, 21 Nov 2025 19:52:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1763754724;
	bh=xfWX1MWedHrZ+OmxiBiUepfssMh2KX6vp847cJtltI0=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=aubBZ50KhxASUsH9f7p2KYtdywmckKytFFSSMWN+M5kMVpFoQmf3P4Ll2z6Ii6ahD
	 jG2YRwfA3fQkhEJbTys06AsOkQrHf74rUejklOCu09/ZdYUehGJjUhCqugC2yKWJSN
	 r07RDzlrwhVteEJ4/URMg+cbxlywBcP2lQBX0HphCs1Rkkn6j9niIQzKe+qY8iJT1l
	 xywqK7xYvLZj/JqUhjCAnmxcJADcEfFobBHy1Yl4dt0mLRE01rmnRjqjNm+WYFG7bV
	 Wlhx0osTVfe080ht8Bgj+FbxpSeombfsqFW9P4kffbHMO1Z3sBoAvuKiqoS4HxlDdp
	 NIX1jQ3UkAK4Q==
Date: Fri, 21 Nov 2025 19:52:02 +0000
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
	Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH] [RFC] mm/fadvise: introduce POSIX_FADV_MLOCK
Message-ID: <aSDC4jlaKSaKgbvc@google.com>
References: <20251121032718.1993528-1-jaegeuk@kernel.org>
 <aR_pCGtcc7ASeA77@casper.infradead.org>
 <aR_ultJzXh1rmOKs@google.com>
 <aSB25FFkLaJkbVfT@casper.infradead.org>
 <aSCpKx9ITAJfoSlw@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aSCpKx9ITAJfoSlw@google.com>

On 11/21, Jaegeuk Kim wrote:
> On 11/21, Matthew Wilcox wrote:
> > On Fri, Nov 21, 2025 at 04:46:14AM +0000, Jaegeuk Kim wrote:
> > > On 11/21, Matthew Wilcox wrote:
> > > > On Fri, Nov 21, 2025 at 03:27:18AM +0000, Jaegeuk Kim wrote:
> > > > > This patch introduces a new POSIX_FADV_MLOCK which 1) invalidates the range of
> > > > > cached pages, 2) sets the mapping as inaccessible, 3) POSIX_FADV_WILLNEED loads
> > > > > pages directly to the inaccessible mapping.
> > > > 
> > > > ... what?
> > > > 
> > > > This seems like something which is completely different from mlock().
> > > > So it needs a different name.
> > > > 
> > > > But I don't understand the point of this, whatever it's called.  Need
> > > > more information.
> > > 
> > > So, the sequence that I'd like to optimize is mmap(MAP_POPULATE) followed
> > > by  mlock(). For example, mmap() takes 1 second to load 4GB data, and mlock()
> > > takes 330ms additionally in order to migrate all the pages into inaccessible
> > > map, IIUC.
> > 
> > Oh, so the MLOCK part is right, but the inaccessible() part is wrong.
> > Inaccessible is special weird guest_memfd crap that has all kinds of
> > side-effects that you don't want.
> > 
> > Wouldn't you get the same effect by calling mlock2(MLOCK_ONFAULT) and
> > then calling readahead() for the desired range?
> 
> Oh, thank you. Let me try.

After checking the code and experiment, I don't think that gives what we need.
That flag skips populate_vma_page_range only, but we need to allocate pages
in the inaccessible mapping and fill the pages afterwards.