On Fri, 11 Jun 2021, Alistair Popple wrote:
> On Friday, 11 June 2021 8:15:05 AM AEST Andrew Morton wrote:
> > On Tue, 8 Jun 2021 20:57:34 -0700 (PDT) Hugh Dickins <[email protected]> wrote:
> >
> > > These are against 5.13-rc5: expect mmotm conflicts with a couple of
> > > Alistair Popple's "Add support for SVM atomics in Nouveau" series:
> > > mm-remove-special-swap-entry-functions.patch
> > > mm-rmap-split-try_to_munlock-from-try_to_unmap.patch
> >
> > I came unstuck at "mm/rmap: split migration into its own function".
Sorry about that, I hadn't yet gotten to trying my latest with mmotm.
And I think my previous mmotm-adjust.tar must have been incomplete;
and even if it were complete, would no longer apply properly anyway.
> >
> > --- mm/huge_memory.c~mm-rmap-split-migration-into-its-own-function
> > +++ mm/huge_memory.c
> > @@ -2345,16 +2345,21 @@ void vma_adjust_trans_huge(struct vm_are
> >
> > static void unmap_page(struct page *page)
> > {
> > - enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
> > - TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
> > + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
> > bool unmap_success;
> >
> > VM_BUG_ON_PAGE(!PageHead(page), page);
> >
> > if (PageAnon(page))
> > - ttu_flags |= TTU_SPLIT_FREEZE;
> > -
> > - unmap_success = try_to_unmap(page, ttu_flags);
> > + unmap_success = try_to_migrate(page, ttu_flags);
> > + else
> > + /*
> > + * Don't install migration entries for file backed pages. This
> > + * helps handle cases when i_size is in the middle of the page
> > + * as there is no need to unmap pages beyond i_size manually.
> > + */
> > + unmap_success = try_to_unmap(page, ttu_flags |
> > + TTU_IGNORE_MLOCK);
> > VM_BUG_ON_PAGE(!unmap_success, page);
> > }
> >
> >
> > Sigh. I have a few todo's against Alastair's "Add support for SVM
> > atomics in Nouveau v9". Including
Sigh shared!
> >
> > https://lkml.kernel.org/r/20210525183710.fa2m2sbfixnhz7g5@revolver
> > https://lkml.kernel.org/r/20210604204934.sbspsmwdqdtmz73d@revolver
> > https://lkml.kernel.org/r/YK6mbf967dV0ljHn@t490s
> > https://lkml.kernel.org/r/2005328.bFqPmhE5MS@nvdebian
> > https://lkml.kernel.org/r/[email protected]
> > https://lkml.kernel.org/r/YK6hYGEx+XzeZELV@t490s
> >
> > So I think I'll drop that series and shall ask for it to be redone
> > against this lot, please.
Thank you, Andrew: that's certainly easiest for you and for me:
and I think the right thing to do for now.
> >
>
> I believe v10 of the series posted earlier this week should address those
> todo's. I will double check though and resend based on top of mmotm. Thanks.
Sorry to give you the bother, Alistair: it's worked out as a bad moment
to rewrite swapops.h and rmap.c, I'm afraid.
And the only help I've had time to give you was pointing Peter at your
series - many thanks to Peter, and to Shakeel.
Several times I've been on the point of asking you to keep the familiar
migration_entry_to_page(), along with your new pfn_swap_entry_to_page();
but each time I've looked, seen that it's hard to retain it sensibly at
the same time as overdue cleanup of the device_private_entry_to_page()s.
So I guess I'm resigned to losing it; but there are at least three
bugs currently under discussion or fixes in flight, which border on
migration_entry_to_page() - Jann Horn's smaps syzbot bug, Xu Yu's
__migration_entry_wait() fix, my __split_huge_pmd_locked() fix
(and page_vma_mapped_walk() cleanup).
And regarding huge_memory.c's unmap_page(): I did not recognize the
"helps handle cases when i_size" comment you added there. What I
ended up with (and thought was in mmotm-adjust.tar but seems not):
/*
* Anon pages need migration entries to preserve them, but file
* pages can simply be left unmapped, then faulted back on demand.
* If that is ever changed (perhaps for mlock), update remap_page().
*/
if (PageAnon(page))
try_to_migrate(page, ttu_flags);
else
try_to_unmap(page, ttu_flags | TTU_IGNORE_MLOCK);
with
/* If try_to_migrate() is used on file, remove this check */
in remap_page() to replace the
/* If TTU_SPLIT_FREEZE is ever extended to file, remove this check */
comment my series puts there (since you delete TTU_SPLIT_FREEZE altogether).
Hugh
On Friday, 11 June 2021 10:15:51 AM AEST Hugh Dickins wrote:
> On Fri, 11 Jun 2021, Alistair Popple wrote:
> > On Friday, 11 June 2021 8:15:05 AM AEST Andrew Morton wrote:
> > > On Tue, 8 Jun 2021 20:57:34 -0700 (PDT) Hugh Dickins <[email protected]> wrote:
> > > --- mm/huge_memory.c~mm-rmap-split-migration-into-its-own-function
> > > +++ mm/huge_memory.c
> > > @@ -2345,16 +2345,21 @@ void vma_adjust_trans_huge(struct vm_are
> > >
> > > static void unmap_page(struct page *page)
> > > {
> > > - enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
> > > - TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
> > > + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
> > > bool unmap_success;
> > >
> > > VM_BUG_ON_PAGE(!PageHead(page), page);
> > >
> > > if (PageAnon(page))
> > > - ttu_flags |= TTU_SPLIT_FREEZE;
> > > -
> > > - unmap_success = try_to_unmap(page, ttu_flags);
> > > + unmap_success = try_to_migrate(page, ttu_flags);
> > > + else
> > > + /*
> > > + * Don't install migration entries for file backed pages. This
> > > + * helps handle cases when i_size is in the middle of the page
> > > + * as there is no need to unmap pages beyond i_size manually.
> > > + */
> > > + unmap_success = try_to_unmap(page, ttu_flags |
> > > + TTU_IGNORE_MLOCK);
> > > VM_BUG_ON_PAGE(!unmap_success, page);
> > > }
> > >
> > >
> > > Sigh. I have a few todo's against Alastair's "Add support for SVM
> > > atomics in Nouveau v9". Including
>
> Sigh shared!
>
> > >
> > > https://lkml.kernel.org/r/20210525183710.fa2m2sbfixnhz7g5@revolver
> > > https://lkml.kernel.org/r/20210604204934.sbspsmwdqdtmz73d@revolver
> > > https://lkml.kernel.org/r/YK6mbf967dV0ljHn@t490s
> > > https://lkml.kernel.org/r/2005328.bFqPmhE5MS@nvdebian
> > > https://lkml.kernel.org/r/[email protected]
> > > https://lkml.kernel.org/r/YK6hYGEx+XzeZELV@t490s
> > >
> > > So I think I'll drop that series and shall ask for it to be redone
> > > against this lot, please.
>
> Thank you, Andrew: that's certainly easiest for you and for me:
> and I think the right thing to do for now.
I guess this is where I sigh :-)
> > >
> >
> > I believe v10 of the series posted earlier this week should address those
> > todo's. I will double check though and resend based on top of mmotm. Thanks.
>
> Sorry to give you the bother, Alistair: it's worked out as a bad moment
> to rewrite swapops.h and rmap.c, I'm afraid.
Indeed, but I don't think it's too bad. I've just tried rebasing it on this
series and it didn't run into too many problems. Obviously I ran into the same
issue Andrew did but I was able to fix that up. It also means try_to_migrate()
now returns 'void' instead of 'bool'.
Which brings me to the only real question I had during the rebase - does
migration also need to accept the TTU_SYNC flag? I think it does because if I
understand correctly we can still hit the same race with zap_pte_range() when
trying to establish migration entries which previously also returned the status
of page_mapped().
> And the only help I've had time to give you was pointing Peter at your
> series - many thanks to Peter, and to Shakeel.
Yes, thanks for the help there. I think the main questions I had for you were
around checking vma flags under the ptl in try_to_munlock_one but Shakeel was
able to clear that up for me. Thanks!
> Several times I've been on the point of asking you to keep the familiar
> migration_entry_to_page(), along with your new pfn_swap_entry_to_page();
> but each time I've looked, seen that it's hard to retain it sensibly at
> the same time as overdue cleanup of the device_private_entry_to_page()s.
Yeah, it would make things a bit funny to retain it IMHO. At least any fixups
should just be simple substitutions.
> So I guess I'm resigned to losing it; but there are at least three
> bugs currently under discussion or fixes in flight, which border on
> migration_entry_to_page() - Jann Horn's smaps syzbot bug, Xu Yu's
> __migration_entry_wait() fix, my __split_huge_pmd_locked() fix
> (and page_vma_mapped_walk() cleanup).
>
> And regarding huge_memory.c's unmap_page(): I did not recognize the
> "helps handle cases when i_size" comment you added there. What I
> ended up with (and thought was in mmotm-adjust.tar but seems not):
>
> /*
> * Anon pages need migration entries to preserve them, but file
> * pages can simply be left unmapped, then faulted back on demand.
> * If that is ever changed (perhaps for mlock), update remap_page().
> */
My comment was based somewhat on the commit message for the original change but
yours is much clearer so will incorporate it into my rebase, thanks.
As to sending my rebased series I suppose it would be best to wait until
linux-mm has been updated with whatever other fixes are needed before resending
it based on top of that. So far rebasing on this series didn't require too many
drastic changes to my v10 series. The most significant was to incorporate your
changes to unmap_page(). The remaining were just adding the TTU_SYNC case to
try_to_migrate{_one} and a single s/migration_entry_to_page/pfn_swap_entry_to_page/
in huge_memory.c
> if (PageAnon(page))
> try_to_migrate(page, ttu_flags);
> else
> try_to_unmap(page, ttu_flags | TTU_IGNORE_MLOCK);
>
> with
> /* If try_to_migrate() is used on file, remove this check */
> in remap_page() to replace the
> /* If TTU_SPLIT_FREEZE is ever extended to file, remove this check */
> comment my series puts there (since you delete TTU_SPLIT_FREEZE altogether).
> Hugh
On Fri, 11 Jun 2021, Alistair Popple wrote:
> On Friday, 11 June 2021 10:15:51 AM AEST Hugh Dickins wrote:
> >
> > Sorry to give you the bother, Alistair: it's worked out as a bad moment
> > to rewrite swapops.h and rmap.c, I'm afraid.
>
> Indeed, but I don't think it's too bad. I've just tried rebasing it on this
> series and it didn't run into too many problems. Obviously I ran into the same
> issue Andrew did but I was able to fix that up. It also means try_to_migrate()
> now returns 'void' instead of 'bool'.
Yes, void try_to_migrate().
>
> Which brings me to the only real question I had during the rebase - does
> migration also need to accept the TTU_SYNC flag? I think it does because if I
> understand correctly we can still hit the same race with zap_pte_range() when
> trying to establish migration entries which previously also returned the status
> of page_mapped().
Yes, try_to_migrate() needs to accept TTU_SYNC too.
>
> > And the only help I've had time to give you was pointing Peter at your
> > series - many thanks to Peter, and to Shakeel.
>
> Yes, thanks for the help there. I think the main questions I had for you were
> around checking vma flags under the ptl in try_to_munlock_one but Shakeel was
> able to clear that up for me. Thanks!
>
> > Several times I've been on the point of asking you to keep the familiar
> > migration_entry_to_page(), along with your new pfn_swap_entry_to_page();
> > but each time I've looked, seen that it's hard to retain it sensibly at
> > the same time as overdue cleanup of the device_private_entry_to_page()s.
>
> Yeah, it would make things a bit funny to retain it IMHO. At least any fixups
> should just be simple substitutions.
>
> > So I guess I'm resigned to losing it; but there are at least three
> > bugs currently under discussion or fixes in flight, which border on
> > migration_entry_to_page() - Jann Horn's smaps syzbot bug, Xu Yu's
> > __migration_entry_wait() fix, my __split_huge_pmd_locked() fix
> > (and page_vma_mapped_walk() cleanup).
> >
> > And regarding huge_memory.c's unmap_page(): I did not recognize the
> > "helps handle cases when i_size" comment you added there. What I
> > ended up with (and thought was in mmotm-adjust.tar but seems not):
> >
> > /*
> > * Anon pages need migration entries to preserve them, but file
> > * pages can simply be left unmapped, then faulted back on demand.
> > * If that is ever changed (perhaps for mlock), update remap_page().
> > */
>
> My comment was based somewhat on the commit message for the original change but
> yours is much clearer so will incorporate it into my rebase, thanks.
Oh, you did better than I, I didn't think to look there on this occasion.
But even so, the i_size business is just one detail, and the new comment
better I think (I also disliked comment on an else without { } around it).
>
> As to sending my rebased series I suppose it would be best to wait until
> linux-mm has been updated with whatever other fixes are needed before resending
> it based on top of that. So far rebasing on this series didn't require too many
> drastic changes to my v10 series. The most significant was to incorporate your
> changes to unmap_page(). The remaining were just adding the TTU_SYNC case to
> try_to_migrate{_one} and a single s/migration_entry_to_page/pfn_swap_entry_to_page/
> in huge_memory.c
Yes, I think that's it. But check your try_to_migrate_one(), it may
want the same range.end vma_address_end() mod I made in try_to_unmap_one().
And does try_to_migrate_one() still have a comment referring to
try_to_unmap() when it should say try_to_migrate() there?
I've now located the diffs I missed from sending akpm before,
and diffed the diffs, and those are the points I see there;
but sending them now will just be a waste of everyones time.
No substitute for me checking your end result when it comes,
though I fear to do so since there's much more in your series
than I can wrap my head around without a lot more education.
Hugh
On Saturday, 12 June 2021 6:56:36 AM AEST Hugh Dickins wrote:
> >
> > As to sending my rebased series I suppose it would be best to wait until
> > linux-mm has been updated with whatever other fixes are needed before resending
> > it based on top of that. So far rebasing on this series didn't require too many
> > drastic changes to my v10 series. The most significant was to incorporate your
> > changes to unmap_page(). The remaining were just adding the TTU_SYNC case to
> > try_to_migrate{_one} and a single s/migration_entry_to_page/pfn_swap_entry_to_page/
> > in huge_memory.c
>
> Yes, I think that's it. But check your try_to_migrate_one(), it may
> want the same range.end vma_address_end() mod I made in try_to_unmap_one().
>
> And does try_to_migrate_one() still have a comment referring to
> try_to_unmap() when it should say try_to_migrate() there?
Thanks for the pointers, I had caught both those as well.
> I've now located the diffs I missed from sending akpm before,
> and diffed the diffs, and those are the points I see there;
> but sending them now will just be a waste of everyones time.
> No substitute for me checking your end result when it comes,
> though I fear to do so since there's much more in your series
> than I can wrap my head around without a lot more education.
The first few patches in the series (and the ones with conflicts) are
clean-ups, so shouldn't change any behaviour. I'm reasonably confident I caught
everything but would certainly appreciate you checking the end result in the
early patches when I post just to make sure I didn't miss anything. Thanks.
Also I have been getting bounce responses trying to deliver mail to linux-mm
in case anyone is wondering why these might not be showing up on the mailing
list. Looks to be some kind of mail loop, but not sure if it's at my end or
somewhere else.
> Hugh
On Sat, 12 Jun 2021, Alistair Popple wrote:
> On Saturday, 12 June 2021 6:56:36 AM AEST Hugh Dickins wrote:
I wonder how I arrived in Queensland - ^^^^ must I quarantine?
> > >
> > > As to sending my rebased series I suppose it would be best to wait until
> > > linux-mm has been updated with whatever other fixes are needed before resending
> > > it based on top of that. So far rebasing on this series didn't require too many
> > > drastic changes to my v10 series. The most significant was to incorporate your
> > > changes to unmap_page(). The remaining were just adding the TTU_SYNC case to
> > > try_to_migrate{_one} and a single s/migration_entry_to_page/pfn_swap_entry_to_page/
> > > in huge_memory.c
> >
> > Yes, I think that's it. But check your try_to_migrate_one(), it may
> > want the same range.end vma_address_end() mod I made in try_to_unmap_one().
> >
> > And does try_to_migrate_one() still have a comment referring to
> > try_to_unmap() when it should say try_to_migrate() there?
>
> Thanks for the pointers, I had caught both those as well.
>
> > I've now located the diffs I missed from sending akpm before,
> > and diffed the diffs, and those are the points I see there;
> > but sending them now will just be a waste of everyones time.
> > No substitute for me checking your end result when it comes,
> > though I fear to do so since there's much more in your series
> > than I can wrap my head around without a lot more education.
>
> The first few patches in the series (and the ones with conflicts) are
> clean-ups, so shouldn't change any behaviour. I'm reasonably confident I caught
> everything but would certainly appreciate you checking the end result in the
> early patches when I post just to make sure I didn't miss anything. Thanks.
>
> Also I have been getting bounce responses trying to deliver mail to linux-mm
> in case anyone is wondering why these might not be showing up on the mailing
> list. Looks to be some kind of mail loop, but not sure if it's at my end or
> somewhere else.
[email protected] has been having trouble recently.
See https://lore.kernel.org/linux-mm/[email protected]/
There are more messages in that thread, but only one has got out.
Hugh