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 CFC9B274FC2 for ; Fri, 21 Nov 2025 04:46:16 +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=1763700377; cv=none; b=uJpuXi6hQTqyJ6H9CHZg6akNMrph2Pt+e7n8mgfFNkeBrmrQONYbWYx9NDsACJRuWFqWcgfv+pi8GFb1Ir3PjQ9XQsyrmJuaztzcihafJ9kdEW33rvX9SCqu98iOFY+sRh8ZzTatA/e+d03XDVR77AnohZBkXkswGMT7zFnub3k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763700377; c=relaxed/simple; bh=8BNbTE9okAQd3oSyfX1xipCtV8nyD1u5qgEglox2ZXA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r/mw06L4OhHwL2k27pTIJE7L24FrbLg7GG/rZJ/aEPi2ao+UV37xs37xq5nZo4vaT8xZyOLlVnvv4JRQ+3jMKQAPPMF/Qhsu8VHs43PiZw5sK1Mo9q+VXWZGDrk+3J5ad7kms4e7lftAPswCCybaH6eFNERYI1ZOkE+iY+EAz0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R2RCW30N; 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="R2RCW30N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 030B2C4CEF1; Fri, 21 Nov 2025 04:46:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763700376; bh=8BNbTE9okAQd3oSyfX1xipCtV8nyD1u5qgEglox2ZXA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R2RCW30NUswCnHncAGnQiPS/Lywv1Q5PwlZhIbzuoPJNGvuE9PgY+JJcjqbSi2K1L giJF2MzTkvJY2/E+KkOjSHMznKWSbsTMjYBUm/k88S42mN8+8euLplxaGLTdw3Q2+M yhD5zw8um5lJjKJXMt7diqW8VUjoPbaTo9UhGzyVQHIeLKD3vYhpgh2uA71FWBB4BP vPbmXYCVl8gJ/qUOPjH+KVnZ5zo4B26Uz23Ohkk2M3WVeEz1sv3mZkMeJu3w1F1mFX 7hk2n5X8lLj3iCe7iKcFT6qbVr9bmsRiDyeaA2HpiY1OMY1zlljVSWV+QG5Ab4ZJUQ va0BqBN972Zlw== Date: Fri, 21 Nov 2025 04:46:14 +0000 From: Jaegeuk Kim To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Christian Brauner Subject: Re: [PATCH] [RFC] mm/fadvise: introduce POSIX_FADV_MLOCK Message-ID: References: <20251121032718.1993528-1-jaegeuk@kernel.org> 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: 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. So, I'm thinking to combine two operations into single fadvise() with whatever advise. Does it make sense? > > > The inaccessible pages will be invalidated by evict_inode or explicit munlock(). > > > > Cc: Matthew Wilcox (Oracle) > > Cc: Christian Brauner > > Signed-off-by: Jaegeuk Kim > > --- > > include/uapi/linux/fadvise.h | 2 ++ > > mm/fadvise.c | 14 ++++++++++++++ > > 2 files changed, 16 insertions(+) > > > > diff --git a/include/uapi/linux/fadvise.h b/include/uapi/linux/fadvise.h > > index 0862b87434c2..06018688b99b 100644 > > --- a/include/uapi/linux/fadvise.h > > +++ b/include/uapi/linux/fadvise.h > > @@ -19,4 +19,6 @@ > > #define POSIX_FADV_NOREUSE 5 /* Data will be accessed once. */ > > #endif > > > > +#define POSIX_FADV_MLOCK 8 /* Load pages into inaccessible map. */ > > + > > #endif /* FADVISE_H_INCLUDED */ > > diff --git a/mm/fadvise.c b/mm/fadvise.c > > index 588fe76c5a14..849b151d2024 100644 > > --- a/mm/fadvise.c > > +++ b/mm/fadvise.c > > @@ -56,6 +56,7 @@ int generic_fadvise(struct file *file, loff_t offset, loff_t len, int advice) > > case POSIX_FADV_WILLNEED: > > case POSIX_FADV_NOREUSE: > > case POSIX_FADV_DONTNEED: > > + case POSIX_FADV_MLOCK: > > /* no bad return value, but ignore advice */ > > break; > > default: > > @@ -93,6 +94,19 @@ int generic_fadvise(struct file *file, loff_t offset, loff_t len, int advice) > > file->f_mode &= ~FMODE_RANDOM; > > spin_unlock(&file->f_lock); > > break; > > + case POSIX_FADV_MLOCK: > > + /* Remove the cached pages. */ > > + if (!mapping_unevictable(mapping)) { > > + invalidate_inode_pages2_range(mapping, > > + offset >> PAGE_SHIFT, > > + (offset + len - 1) >> PAGE_SHIFT); > > + > > + /* set the mapping is unevictable */ > > + filemap_invalidate_lock(mapping); > > + mapping_set_inaccessible(mapping); > > + filemap_invalidate_unlock(mapping); > > + } > > + fallthrough; > > case POSIX_FADV_WILLNEED: > > /* First and last PARTIAL page! */ > > start_index = offset >> PAGE_SHIFT; > > -- > > 2.52.0.487.g5c8c507ade-goog > >