All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] [RFC] mm/fadvise: introduce POSIX_FADV_MLOCK
Date: Fri, 21 Nov 2025 04:46:14 +0000	[thread overview]
Message-ID: <aR_ultJzXh1rmOKs@google.com> (raw)
In-Reply-To: <aR_pCGtcc7ASeA77@casper.infradead.org>

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) <willy@infradead.org>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  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
> > 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
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
Date: Fri, 21 Nov 2025 04:46:14 +0000	[thread overview]
Message-ID: <aR_ultJzXh1rmOKs@google.com> (raw)
In-Reply-To: <aR_pCGtcc7ASeA77@casper.infradead.org>

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) <willy@infradead.org>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  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
> > 

  reply	other threads:[~2025-11-21  4:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21  3:27 [f2fs-dev] [PATCH] [RFC] mm/fadvise: introduce POSIX_FADV_MLOCK Jaegeuk Kim via Linux-f2fs-devel
2025-11-21  3:27 ` Jaegeuk Kim
2025-11-21  4:22 ` [f2fs-dev] " Matthew Wilcox
2025-11-21  4:22   ` Matthew Wilcox
2025-11-21  4:46   ` Jaegeuk Kim via Linux-f2fs-devel [this message]
2025-11-21  4:46     ` Jaegeuk Kim
2025-11-21 14:27     ` [f2fs-dev] " Matthew Wilcox
2025-11-21 14:27       ` Matthew Wilcox
2025-11-21 18:02       ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2025-11-21 18:02         ` Jaegeuk Kim
2025-11-21 19:52         ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2025-11-21 19:52           ` Jaegeuk Kim
2025-11-21 19:58           ` [f2fs-dev] " Matthew Wilcox
2025-11-21 19:58             ` Matthew Wilcox
2025-11-21 21:32             ` [f2fs-dev] " Jaegeuk Kim via Linux-f2fs-devel
2025-11-21 21:32               ` Jaegeuk Kim
2025-11-22  2:47               ` [f2fs-dev] " Matthew Wilcox
2025-11-22  2:47                 ` Matthew Wilcox

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=aR_ultJzXh1rmOKs@google.com \
    --to=linux-f2fs-devel@lists.sourceforge.net \
    --cc=brauner@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@infradead.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.