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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx 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
