All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: akpm@linux-foundation.org, hca@linux.ibm.com,
	linux-s390@vger.kernel.org, david@kernel.org, mhocko@suse.com,
	brauner@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, surenb@google.com,
	timmurray@google.com
Subject: Re: [PATCH v1 1/3] mm: process_mrelease: expedite clean file folio reclaim via mmu_gather
Date: Fri, 24 Apr 2026 14:56:47 -0700	[thread overview]
Message-ID: <aevnH-0yVstaPjiJ@google.com> (raw)
In-Reply-To: <aevFb-ZemUo4nB3I@casper.infradead.org>

On Fri, Apr 24, 2026 at 08:33:03PM +0100, Matthew Wilcox wrote:
> On Tue, Apr 21, 2026 at 04:02:37PM -0700, Minchan Kim wrote:
> > +++ b/mm/swap.c
> > @@ -1043,6 +1043,48 @@ void release_pages(release_pages_arg arg, int nr)
> >  }
> >  EXPORT_SYMBOL(release_pages);
> >  
> > +static inline void free_file_cache(struct folio *folio)
> > +{
> > +	if (folio_trylock(folio)) {
> > +		mapping_evict_folio(folio_mapping(folio), folio);
> 
> If we already know that the folio is for a file (and I think we do?)
> then we can just use folio->mapping here.  On the other hand, if it
> could be KSM or something else weird, carry on.

Thanks for the review. It made me think about the shmem corner cases.

Since we already check folio_test_anon(folio) before calling this path,
we know we are dealing with non-anonymous folios.

My specific concern was shmem folios, which are not anonymous but can
be in the swap cache. While mapping_evict_folio() might technically work
for them at this point (since remove_mapping handles it but I might miss),
it feels unintentional and fragile because mapping_evict_folio() is
primarily designed for page cache eviction, not swap cache.

To make this robust and safely adopt your suggestion of using folio->mapping
directly, I think we should handle swap cache folios explicitly
in the main loop like this:

void free_pages_and_caches(struct encoded_page **pages, int nr,
		       bool try_evict_file_folios)
{
    for (int i = 0; i < nr; i++) {
	    struct folio *folio = page_folio(encoded_page_ptr(pages[i]));

	    if (folio_test_anon(folio) || folio_test_swapcache(folio))
		    free_swap_cache(folio);
	    else if (unlikely(try_evict_file_folios))
		    free_file_cache(folio);
	    ...
    }
}

And then we can use folio->mapping directly in the helper:

static inline void free_file_cache(struct folio *folio)
{
    if (folio_trylock(folio)) {
	    mapping_evict_folio(folio->mapping, folio);
	    folio_unlock(folio);
    }
}

This way, we are guaranteed that anything reaching free_file_cache() is a
non-swapcache file folio, making the direct use of folio->mapping safe.

Please let me know if I am missing something here.


  reply	other threads:[~2026-04-24 21:56 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 23:02 [PATCH v1 0/3] mm: process_mrelease: expedite clean file folio reclaim and add auto-kill Minchan Kim
2026-04-21 23:02 ` [PATCH v1 1/3] mm: process_mrelease: expedite clean file folio reclaim via mmu_gather Minchan Kim
2026-04-24  7:56   ` David Hildenbrand (Arm)
2026-04-24 21:24     ` Minchan Kim
2026-04-27  9:29       ` David Hildenbrand (Arm)
2026-04-27 22:04         ` Minchan Kim
2026-04-24 19:33   ` Matthew Wilcox
2026-04-24 21:56     ` Minchan Kim [this message]
2026-05-05 14:53   ` Alexander Gordeev
2026-05-08 21:56     ` Minchan Kim
2026-05-11 16:13       ` Alexander Gordeev
2026-05-11 21:48         ` Minchan Kim
2026-04-21 23:02 ` [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios Minchan Kim
2026-04-22  7:22   ` Baolin Wang
2026-04-23 23:38     ` Minchan Kim
2026-04-24  7:51   ` Michal Hocko
2026-04-24  7:57     ` David Hildenbrand (Arm)
2026-04-24 19:15       ` Minchan Kim
2026-04-27  7:16         ` Michal Hocko
2026-04-27 16:48           ` Suren Baghdasaryan
2026-04-27 17:15             ` Michal Hocko
2026-04-27 23:05               ` Minchan Kim
2026-04-28  6:56                 ` Michal Hocko
2026-04-29  1:19                   ` Minchan Kim
2026-04-29  8:18                     ` Michal Hocko
2026-04-29  9:09                       ` David Hildenbrand (Arm)
2026-04-29 10:33                         ` Michal Hocko
2026-04-29 13:07                           ` David Hildenbrand (Arm)
2026-04-29 14:44                             ` Michal Hocko
2026-04-30  6:08                               ` David Hildenbrand (Arm)
2026-05-08 20:57                                 ` Liam R. Howlett
2026-05-11 13:05                                   ` David Hildenbrand (Arm)
2026-05-13  6:47                                   ` Michal Hocko
2026-04-29 21:41                         ` Minchan Kim
2026-04-30 14:38                           ` David Hildenbrand (Arm)
2026-04-29  8:55                     ` David Hildenbrand (Arm)
2026-04-29 21:42                       ` Minchan Kim
2026-04-24 19:26     ` Minchan Kim
2026-04-21 23:02 ` [PATCH v1 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag Minchan Kim
2026-04-24  7:57   ` Michal Hocko
2026-04-24 22:49     ` Minchan Kim
2026-04-27  7:02       ` Michal Hocko
2026-04-27 22:03         ` Minchan Kim
2026-04-28  7:01           ` Michal Hocko
2026-04-28 22:37             ` Minchan Kim
2026-04-29  8:25               ` Michal Hocko
2026-04-29 20:01                 ` Suren Baghdasaryan
2026-04-29 21:17                   ` Minchan Kim
2026-04-29 21:16                 ` Minchan Kim
2026-04-27 20:34   ` Suren Baghdasaryan
2026-04-27 22:52     ` Minchan Kim

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=aevnH-0yVstaPjiJ@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=surenb@google.com \
    --cc=timmurray@google.com \
    --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.