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@xxxxxxxxxxxxx/
> 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.
