On 08/22/23 04:32, Matthew Wilcox wrote:
> On Mon, Aug 21, 2023 at 08:13:00PM -0700, Mike Kravetz wrote:
> > On 08/16/23 16:11, Matthew Wilcox (Oracle) wrote:
> > > We can use a bit in page[1].flags to indicate that this folio belongs
> > > to hugetlb instead of using a value in page[1].dtors. That lets
> > > folio_test_hugetlb() become an inline function like it should be.
> > > We can also get rid of NULL_COMPOUND_DTOR.
> >
> > Not 100% sure yet, but I suspect this patch/series causes the following
> > BUG in today's linux-next. I can do a deeper dive tomorrow.
> >
> > # echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> > # echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> >
> > [ 352.631099] page:ffffea0007a30000 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x1e8c00
> > [ 352.633674] head:ffffea0007a30000 order:8 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>
> order 8? Well, that's exciting. This is clearly x86, so it should be
> order 9. Did we mistakenly clear bit 0 of tail->flags?
>
> Oh. Oh yes, we do.
>
> __update_and_free_hugetlb_folio:
>
> for (i = 0; i < pages_per_huge_page(h); i++) {
> subpage = folio_page(folio, i);
> subpage->flags &= ~(1 << PG_locked | 1 << PG_error |
> 1 << PG_referenced | 1 << PG_dirty |
> 1 << PG_active | 1 << PG_private |
> 1 << PG_writeback);
> }
>
> locked PF_NO_TAIL
> error PF_NO_TAIL
> referenced PF_HEAD
> dirty PF_HEAD
> active PF_HEAD
> private PF_ANY
> writeback PF_NO_TAIL
>
> So it seems to me there's no way to set any of these bits other than
> PG_private. And, well, you control PG_private in hugetlbfs. Do you
> ever set it on tail pages?
Nope
>
> I think you can remove this entire loop and be happy?
I believe you are correct. Although, this is clearing flags in the head
page as well as tail pages. So, I think we still need to clear referenced,
dirty and active as well as private on the head page.
Will take a look today.
--
Mike Kravetz
