[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR11MB3495AA8A91C2E2D9492C38B9F7709@BYAPR11MB3495.namprd11.prod.outlook.com>
Date: Tue, 23 Aug 2022 13:29:45 +0000
From: "Wang, Haiyue" <haiyue.wang@...el.com>
To: David Hildenbrand <david@...hat.com>,
Miaohe Lin <linmiaohe@...wei.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"apopple@...dia.com" <apopple@...dia.com>,
"Huang, Ying" <ying.huang@...el.com>,
"songmuchun@...edance.com" <songmuchun@...edance.com>,
"naoya.horiguchi@...ux.dev" <naoya.horiguchi@...ux.dev>,
"alex.sierra@....com" <alex.sierra@....com>,
Felix Kuehling <Felix.Kuehling@....com>
Subject: RE: [PATCH v6 2/2] mm: fix the handling Non-LRU pages returned by
follow_page
> -----Original Message-----
> From: David Hildenbrand <david@...hat.com>
> Sent: Tuesday, August 23, 2022 21:28
> To: Wang, Haiyue <haiyue.wang@...el.com>; Miaohe Lin <linmiaohe@...wei.com>; linux-mm@...ck.org;
> linux-kernel@...r.kernel.org
> Cc: akpm@...ux-foundation.org; apopple@...dia.com; Huang, Ying <ying.huang@...el.com>;
> songmuchun@...edance.com; naoya.horiguchi@...ux.dev; alex.sierra@....com; Felix Kuehling
> <Felix.Kuehling@....com>
> Subject: Re: [PATCH v6 2/2] mm: fix the handling Non-LRU pages returned by follow_page
>
> On 23.08.22 15:26, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: David Hildenbrand <david@...hat.com>
> >> Sent: Tuesday, August 23, 2022 18:07
> >> To: Miaohe Lin <linmiaohe@...wei.com>; Wang, Haiyue <haiyue.wang@...el.com>; linux-mm@...ck.org;
> >> linux-kernel@...r.kernel.org
> >> Cc: akpm@...ux-foundation.org; apopple@...dia.com; Huang, Ying <ying.huang@...el.com>;
> >> songmuchun@...edance.com; naoya.horiguchi@...ux.dev; alex.sierra@....com; Felix Kuehling
> >> <Felix.Kuehling@....com>
> >> Subject: Re: [PATCH v6 2/2] mm: fix the handling Non-LRU pages returned by follow_page
> >>
> >> On 17.08.22 04:34, Miaohe Lin wrote:
> >>> On 2022/8/16 10:21, Haiyue Wang wrote:
> >>>> The handling Non-LRU pages returned by follow_page() jumps directly, it
> >>>> doesn't call put_page() to handle the reference count, since 'FOLL_GET'
> >>>> flag for follow_page() has get_page() called. Fix the zone device page
> >>>> check by handling the page reference count correctly before returning.
> >>>>
> >>>> And as David reviewed, "device pages are never PageKsm pages". Drop this
> >>>> zone device page check for break_ksm().
> >>>>
> >>>> Fixes: 3218f8712d6b ("mm: handling Non-LRU pages returned by vm_normal_pages")
> >>>> Signed-off-by: Haiyue Wang <haiyue.wang@...el.com>
> >>>> Reviewed-by: "Huang, Ying" <ying.huang@...el.com>
> >>>> Reviewed-by: Felix Kuehling <Felix.Kuehling@....com>
> >>>
> >>> Thanks for your fixing. LGTM with one nit below. But I have no strong opinion on it.
> >>> So with or without fixing below nit:
> >>>
> >>> Reviewed-by: Miaohe Lin <linmiaohe@...wei.com>
> >>>
> >>>> ---
> >>>> mm/huge_memory.c | 4 ++--
> >>>> mm/ksm.c | 12 +++++++++---
> >>>> mm/migrate.c | 19 ++++++++++++-------
> >>>> 3 files changed, 23 insertions(+), 12 deletions(-)
> >>>>
> >>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> >>>> index 8a7c1b344abe..b2ba17c3dcd7 100644
> >>>> --- a/mm/huge_memory.c
> >>>> +++ b/mm/huge_memory.c
> >>>> @@ -2963,10 +2963,10 @@ static int split_huge_pages_pid(int pid, unsigned long vaddr_start,
> >>>> /* FOLL_DUMP to ignore special (like zero) pages */
> >>>> page = follow_page(vma, addr, FOLL_GET | FOLL_DUMP);
> >>>>
> >>>> - if (IS_ERR_OR_NULL(page) || is_zone_device_page(page))
> >>>> + if (IS_ERR_OR_NULL(page))
> >>>> continue;
> >>>>
> >>>> - if (!is_transparent_hugepage(page))
> >>>> + if (is_zone_device_page(page) || !is_transparent_hugepage(page))
> >>>
> >>> !is_transparent_hugepage should already do the work here? IIRC, zone_device_page can't be
> >>> a transhuge page anyway. And only transparent_hugepage is cared here.
> >>
> >> I agree.
> >
> > OK, will remove it in next version.
> >
> >>
> >> Can we avoid sending a new version of a patch series as reply to another
> >> patch series (previous version)?
> >
> > Don't use '--in-reply-to=' when running 'git send-email' ?
>
> Yes. That makes it easier top identify versions of patch series, without
> having to dig down into an ever-growing thread.
Got it, thanks. ;-)
>
> --
> Thanks,
>
> David / dhildenb
Powered by blists - more mailing lists