From: Peter Xu <peterx@redhat.com>
To: Yang Shi <shy828301@gmail.com>
Cc: David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Alistair Popple <apopple@nvidia.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Johannes Weiner <hannes@cmpxchg.org>,
John Hubbard <jhubbard@nvidia.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
Muhammad Usama Anjum <usama.anjum@collabora.com>,
Hugh Dickins <hughd@google.com>, Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH 0/4] mm: Fix pmd_trans_unstable() call sites on retry
Date: Wed, 7 Jun 2023 14:22:17 -0400 [thread overview]
Message-ID: <ZIDK2a6qf1SYF/kW@x1n> (raw)
In-Reply-To: <CAHbLzkoiSW3jOhFdEU5w567SyxhB05dBfTrJvKg4X59nPURz3Q@mail.gmail.com>
On Wed, Jun 07, 2023 at 09:39:44AM -0700, Yang Shi wrote:
> I don't think this is an important thing. There are plenty of other
> conditions that could make the accounting inaccurate, for example,
> isolating page from LRU fails, force charge, etc. And it seems like
> nobody was bothered by this either.
Yes, I read that a bit more and I agree. So let me summarize after I read
Hugh's series just now..
With the pre-requisite of the new __pte_map_offset() that Hugh proposed
here:
[PATCH 04/31] mm/pgtable: allow pte_offset_map[_lock]() to fail
https://lore.kernel.org/r/8218ffdc-8be-54e5-0a8-83f5542af283@google.com
We should not need pmd_trans_unstable() anymore as Hugh pointed out, which
I fully agree. I think Hugh has covered all the issues that this series
wanted to address alongside, namely:
Patch 1 (mprotect) is covered in:
[PATCH 18/31] mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()
https://lore.kernel.org/r/4a834932-9064-9ed7-3cd1-99466f549486@google.com
No way to move spinlock outside, so one -EAGAIN needed which makes sense.
Patch 2 (migrate_device) is covered in:
[PATCH 24/31] mm/migrate_device: allow pte_offset_map_lock() to fail
https://lore.kernel.org/r/ea51bb69-189c-229b-fc0-9d3e7be5d6b@google.com
By a direct retry, and more code unified so even better.
Patch 3 () is covered in:
[PATCH 19/31] mm/mremap: retry if either pte_offset_map_*lock() fails
https://lore.kernel.org/r/2d3fbfea-5884-8211-0cc-954afe25ae9c@google.com
Instead of WARN_ON_ONCE(), it got dropped which looks all good, too.
Most of patch 4's changes are done in:
[PATCH 09/31] mm/pagewalkers: ACTION_AGAIN if pte_offset_map_lock() fails
https://lore.kernel.org/r/6265ac58-6018-a8c6-cf38-69cba698471@google.com
There're some different handling on memcg changes, where in Hugh's
series it was put separately here:
[PATCH 17/31] mm/various: give up if pte_offset_map[_lock]() fails
https://lore.kernel.org/r/c299eba-4e17-c645-1115-ccd1fd9956bd@google.com
After double check, I agree with Yang's comment and Hugh's approach,
that no retry is needed for memcg.
Let's ignore this series, not needed anymore.
Thanks,
--
Peter Xu
prev parent reply other threads:[~2023-06-07 18:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 23:05 [PATCH 0/4] mm: Fix pmd_trans_unstable() call sites on retry Peter Xu
2023-06-02 23:05 ` [PATCH 1/4] mm/mprotect: Retry on pmd_trans_unstable() Peter Xu
2023-06-03 2:04 ` Yang Shi
2023-06-04 23:58 ` Peter Xu
2023-06-02 23:05 ` [PATCH 2/4] mm/migrate: Unify and retry an unstable pmd when hit Peter Xu
2023-06-02 23:05 ` [PATCH 3/4] mm: Warn for unstable pmd in move_page_tables() Peter Xu
2023-06-02 23:05 ` [PATCH 4/4] mm: Make most walk page paths with pmd_trans_unstable() to retry Peter Xu
2023-06-05 18:46 ` Yang Shi
2023-06-05 19:20 ` Peter Xu
2023-06-06 19:12 ` Yang Shi
2023-06-06 19:59 ` Peter Xu
2023-06-07 13:49 ` [PATCH 0/4] mm: Fix pmd_trans_unstable() call sites on retry Peter Xu
2023-06-07 15:45 ` David Hildenbrand
2023-06-07 16:21 ` Peter Xu
2023-06-07 16:39 ` Yang Shi
2023-06-07 18:22 ` Peter Xu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZIDK2a6qf1SYF/kW@x1n \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jhubbard@nvidia.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naoya.horiguchi@nec.com \
--cc=rppt@kernel.org \
--cc=shy828301@gmail.com \
--cc=usama.anjum@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.