[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOUHufYnLeggF+34-L_Yn-UUyRb+ZnTzmByy-wL-3xrfdrycEw@mail.gmail.com>
Date: Tue, 9 Jul 2024 16:30:06 -0600
From: Yu Zhao <yuzhao@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Bharata B Rao <bharata@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH mm-unstable v1] mm/truncate: batch-clear shadow entries
On Mon, Jul 8, 2024 at 4:36 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Mon, Jul 08, 2024 at 03:27:53PM -0600, Yu Zhao wrote:
> > Make clear_shadow_entry() clear shadow entries in `struct folio_batch`
> > so that it can reduce contention on i_lock and i_pages locks, e.g.,
>
> I think it needs to be renamed, perhaps to clear_shadow_entries().
Yes, thank you.
> > @@ -503,8 +486,8 @@ unsigned long mapping_try_invalidate(struct address_space *mapping,
> > /* We rely upon deletion not changing folio->index */
> >
> > if (xa_is_value(folio)) {
> > - count += invalidate_exceptional_entry(mapping,
> > - indices[i], folio);
> > + xa_has_values = true;
> > + count++;
>
> Mmm. This is awkward. It's supposed to return the number of pages,
> not the number of folios (or shadow entries) invalidated.
I didn't think about this much. It seems to me no callers really care
about it other than some debugging messages?
Powered by blists - more mailing lists