Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1206b559-2917-2ce0-6c54-ec78727b826d@redhat.com>
Date:   Tue, 23 Aug 2022 15:27:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v6 2/2] mm: fix the handling Non-LRU pages returned by
 follow_page
Content-Language: en-US
To:     "Wang, Haiyue" <haiyue.wang@intel.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc:     "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "apopple@nvidia.com" <apopple@nvidia.com>,
        "Huang, Ying" <ying.huang@intel.com>,
        "songmuchun@bytedance.com" <songmuchun@bytedance.com>,
        "naoya.horiguchi@linux.dev" <naoya.horiguchi@linux.dev>,
        "alex.sierra@amd.com" <alex.sierra@amd.com>,
        Felix Kuehling <Felix.Kuehling@amd.com>
References: <20220812084921.409142-1-haiyue.wang@intel.com>
 <20220816022102.582865-1-haiyue.wang@intel.com>
 <20220816022102.582865-3-haiyue.wang@intel.com>
 <f9bb1faf-3e09-2db4-5210-4cea09654452@huawei.com>
 <36925544-8127-fe0c-76e5-49138dff45ae@redhat.com>
 <BYAPR11MB3495477AF580B94D1EA75108F7709@BYAPR11MB3495.namprd11.prod.outlook.com>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
In-Reply-To: <BYAPR11MB3495477AF580B94D1EA75108F7709@BYAPR11MB3495.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 23.08.22 15:26, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: David Hildenbrand <david@redhat.com>
>> Sent: Tuesday, August 23, 2022 18:07
>> To: Miaohe Lin <linmiaohe@huawei.com>; Wang, Haiyue <haiyue.wang@intel.com>; linux-mm@kvack.org;
>> linux-kernel@vger.kernel.org
>> Cc: akpm@linux-foundation.org; apopple@nvidia.com; Huang, Ying <ying.huang@intel.com>;
>> songmuchun@bytedance.com; naoya.horiguchi@linux.dev; alex.sierra@amd.com; Felix Kuehling
>> <Felix.Kuehling@amd.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@intel.com>
>>>> Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
>>>> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.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@huawei.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.

-- 
Thanks,

David / dhildenb