Messages in this thread | | | From | "Wang, Haiyue" <> | Subject | RE: [PATCH v3 1/2] mm: migration: fix the FOLL_GET failure on following huge page | Date | Mon, 15 Aug 2022 02:10:59 +0000 |
| |
> -----Original Message----- > From: Huang, Ying <ying.huang@intel.com> > Sent: Monday, August 15, 2022 09:59 > To: Wang, Haiyue <haiyue.wang@intel.com> > Cc: linux-mm@kvack.org; linux-kernel@vger.kernel.org; akpm@linux-foundation.org; david@redhat.com; > linmiaohe@huawei.com; songmuchun@bytedance.com; naoya.horiguchi@linux.dev; alex.sierra@amd.com > Subject: Re: [PATCH v3 1/2] mm: migration: fix the FOLL_GET failure on following huge page > > Haiyue Wang <haiyue.wang@intel.com> writes: > > > Not all huge page APIs support FOLL_GET option, so the __NR_move_pages > > move_pages() is a syscall, so you can just call it move_pages(), or > move_pages() syscall.
The application meets the issue, use the bellow function: syscall (__NR_move_pages, 0, n_pages, ptr, 0, status, 0)
So I used it directly in the commit. "move_pages() syscall" is better. Will update latter.
> > > will fail to get the page node information for huge page. > ~~~~~~~~~ > some huge pages?
OK.
> > > This is an temporary solution to mitigate the racing fix. > > Why is it "racing fix"? This isn't a race condition fix.
The 'Fixes' commit is about race condition fix.
How about " his is an temporary solution to mitigate the side effect Of the race condition fix"
> > Best Regards, > Huang, Ying > > > After supporting follow huge page by FOLL_GET is done, this fix can be > > reverted safely. > > > > Fixes: 4cd614841c06 ("mm: migration: fix possible do_pages_stat_array racing with memory offline") > > Signed-off-by: Haiyue Wang <haiyue.wang@intel.com> > > [snip]
| |