| Message ID | 20210325002835.216118-1-mike.kravetz@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | make hugetlb put_page safe for all calling contexts | expand |
Hi: On 2021/3/25 8:28, Mike Kravetz wrote: > This effort is the result a recent bug report [1]. In subsequent > discussions [2], it was deemed necessary to properly fix the hugetlb Many thanks for the effort. I have read the discussions and it is pretty long. Maybe it would be helpful if you give a brief summary here? > put_page path (free_huge_page). This RFC provides a possible way to trival: Not RFC here. > address the issue. Comments are welcome/encouraged as several attempts > at this have been made in the past. > > This series is based on v5.12-rc3-mmotm-2021-03-17-22-24. At a high > level, the series provides: > - Patches 1 & 2 from Roman Gushchin provide cma_release_nowait() trival: missing description of the Patches 3 ? > - Patches 4, 5 & 6 are aimed at reducing lock hold times. To be clear > the goal is to eliminate single lock hold times of a long duration. > Overall lock hold time is not addressed. > - Patch 7 makes hugetlb_lock and subpool lock IRQ safe. It also reverts > the code which defers calls to a workqueue if !in_task. > - Patch 8 adds some lockdep_assert_held() calls > > [1] https://lore.kernel.org/linux-mm/000000000000f1c03b05bc43aadc@google.com/ > [2] http://lkml.kernel.org/r/20210311021321.127500-1-mike.kravetz@oracle.com > > RFC -> v1 > - Add Roman's cma_release_nowait() patches. This eliminated the need > to do a workqueue handoff in hugetlb code. > - Use Michal's suggestion to batch pages for freeing. This eliminated > the need to recalculate loop control variables when dropping the lock. > - Added lockdep_assert_held() calls > - Rebased to v5.12-rc3-mmotm-2021-03-17-22-24 > > Mike Kravetz (6): > hugetlb: add per-hstate mutex to synchronize user adjustments > hugetlb: create remove_hugetlb_page() to separate functionality > hugetlb: call update_and_free_page without hugetlb_lock > hugetlb: change free_pool_huge_page to remove_pool_huge_page > hugetlb: make free_huge_page irq safe > hugetlb: add lockdep_assert_held() calls for hugetlb_lock > > Roman Gushchin (2): > mm: cma: introduce cma_release_nowait() > mm: hugetlb: don't drop hugetlb_lock around cma_release() call > > include/linux/cma.h | 2 + > include/linux/hugetlb.h | 1 + > mm/cma.c | 93 +++++++++++ > mm/cma.h | 5 + > mm/hugetlb.c | 354 +++++++++++++++++++++------------------- > mm/hugetlb_cgroup.c | 8 +- > 6 files changed, 294 insertions(+), 169 deletions(-) >
On 3/25/21 6:42 PM, Miaohe Lin wrote: > Hi: > On 2021/3/25 8:28, Mike Kravetz wrote: >> This effort is the result a recent bug report [1]. In subsequent >> discussions [2], it was deemed necessary to properly fix the hugetlb > > Many thanks for the effort. I have read the discussions and it is pretty long. > Maybe it would be helpful if you give a brief summary here? > >> put_page path (free_huge_page). This RFC provides a possible way to > > trival: Not RFC here. > >> address the issue. Comments are welcome/encouraged as several attempts >> at this have been made in the past. >>> This series is based on v5.12-rc3-mmotm-2021-03-17-22-24. At a high >> level, the series provides: >> - Patches 1 & 2 from Roman Gushchin provide cma_release_nowait() > > trival: missing description of the Patches 3 ? > Thanks, I will clean this up with next version.