On Tue, Dec 21, 2021 at 11:07 AM Yang Shi <shy828301@xxxxxxxxx> wrote:
>
> On Tue, Dec 21, 2021 at 10:40 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> >
> > On Tue, Dec 21, 2021 at 10:24:27AM -0800, Yang Shi wrote:
> > > It seems the THP is split during smaps walk. The reproducer does call
> > > MADV_FREE on partial THP which may split the huge page.
> > >
> > > The below fix (untested) should be able to fix it.
> >
> > Did you read the rest of the thread on this? If the page is being
> > migrated, we should still account it ... also, you've changed the
>
> Yes, the being migrated pages may be skipped. We should be able to add
> a new flag to smaps_account() to indicate this is a migration entry
> then don't elevate the page count.
It seems not that straightforward. THP split converts PTEs to
migration entries too. So we can't tell if it is real migration or
just in the middle of THP split.
We just need to serialize against THP split for PTE mapped subpages.
So in real life workload it might be ok to skip accounting migration
pages? Typically the migration is a transient state, so the under
accounting should be transient too. Or account migration pages
separately, just like swap entries?
I may revisit this after the holiday. If you have any better ideas,
please feel free to propose.
>
> > refcount, so this:
> >
> > if (page_count(page) == 1) {
> > smaps_page_accumulate(mss, page, size, size << PSS_SHIFT, dirty,
> > locked, true);
> > return;
> > }
> >
> > will never trigger.
>
> The get_page_unless_zero() is called after this block.
