[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZOTR3wJP5m6qgwaF@casper.infradead.org>
Date: Tue, 22 Aug 2023 16:18:55 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Peter Xu <peterx@...hat.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Yang Shi <shy828301@...il.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
David Hildenbrand <david@...hat.com>,
"Kirill A . Shutemov" <kirill@...temov.name>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: Wire up tail page poisoning over ->mappings
On Mon, Aug 21, 2023 at 12:48:18PM -0400, Peter Xu wrote:
> On Mon, Aug 21, 2023 at 03:29:01AM +0100, Matthew Wilcox wrote:
> > On Sun, Aug 20, 2023 at 09:13:55PM -0400, Peter Xu wrote:
> > > Setting tail mapping for tail 1/2 is even wrong, which part of this patch
> > > fixes:
> > >
> > > @@ -428,7 +428,8 @@ static inline void prep_compound_tail(struct page *head, int tail_idx)
> > > {
> > > struct page *p = head + tail_idx;
> > >
> > > - p->mapping = TAIL_MAPPING;
> > > + if (tail_idx > TAIL_MAPPING_REUSED_MAX)
> > > + p->mapping = TAIL_MAPPING;
> > > set_compound_head(p, head);
> > > set_page_private(p, 0);
> > > }
> >
> > I didn't see this. This is wrong. tail->mapping is only reused for
> > large rmappable pages. It's not reused for other compound pages.
>
> Just to make sure we're on the same page: I think it's not only
> _deferred_list (of tail page 2) that reused the mapping field (word offset
> 3), but also _nr_pages_mapped (of tail page 1)?
I don't see how this comment is related to the part of the email you're
replying to. But yes, prep_large_rmappable overwrites ->mapping in
two tail pages.
> > However, I have a small patch series which enables 'allnoconfig' to
> > build after renaming page->mapping to page->_mapping. Aside from fs/
> > there are *very* few places which look at page->mapping [1]. I'll post
> > that patch series tomorrow.
>
> Assuming it's still not yet posted; I can wait and read it.
I sent out a few patches. Some have made it to -next already because
they're almost trivial. Nobody's commented on the difficult one.
https://lore.kernel.org/linux-mm/20230821202016.2910321-1-willy@infradead.org/
> If you plan to remove the whole TAIL_MAPPING in a few days then I agree
> this patch is not needed, but so far I don't know when it'll land and also
> why, before that it does sound like we can still keep this patch.
This patch is putting fresh paint on a condemned building. Just stop
it.
> Regarding the question on "why removing TAIL_MAPPING": poisoning an unused
> field is always helpful to me even if not referenced with "page->mapping".
> So I don't see an immediate benefit from removing the poisoning if it's
> already there; OTOH not sure whether poison more unused fields will be more
> helpful in general?
You are wrong.
Powered by blists - more mailing lists