[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z31X5L1VyLhG0I7C@casper.infradead.org>
Date: Tue, 7 Jan 2025 16:35:48 +0000
From: Matthew Wilcox <willy@...radead.org>
To: David Hildenbrand <david@...hat.com>
Cc: Yu Zhao <yuzhao@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
Mateusz Guzik <mjguzik@...il.com>,
Muchun Song <muchun.song@...ux.dev>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Will Deacon <will@...nel.org>
Subject: Re: [PATCH mm-unstable v1] mm/hugetlb_vmemmap: fix memory loads
ordering
On Tue, Jan 07, 2025 at 09:49:18AM +0100, David Hildenbrand wrote:
> > +++ b/include/linux/page-flags.h
> > @@ -212,7 +212,7 @@ static __always_inline const struct page *page_fixed_fake_head(const struct page
> > * cold cacheline in some cases.
> > */
> > if (IS_ALIGNED((unsigned long)page, PAGE_SIZE) &&
> > - test_bit(PG_head, &page->flags)) {
> > + test_bit_acquire(PG_head, &page->flags)) {
>
> This change will affect all page_fixed_fake_head() users, like ordinary
> PageTail even on !hugetlb.
I've been looking at the callers of PageTail() because it's going to
be a bit of a weird thing to be checking in the separate-page-and-folio
world. Obviously we can implement it, but there's a bit of a "But why
would you want to ask that question" question.
Most current occurrences of PageTail() are in assertions of one form or
another. Fair enough, not performance critical.
make_device_exclusive_range() is a little weird; looks like it's trying
to make sure that each folio is only made exclusive once, and ignore any
partial folios which overlap the start of the area.
damon_get_folio() wants to fail for tail pages. Fair enough.
split_huge_pages_all() is debug code.
page_idle_get_folio() is like damon.
That's it. We don't seem to have any PageTail() callers in critical
code any more.
Powered by blists - more mailing lists