[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191121010536.GA12975@richard>
Date: Thu, 21 Nov 2019 09:05:36 +0800
From: Wei Yang <richardw.yang@...ux.intel.com>
To: David Hildenbrand <david@...hat.com>
Cc: Wei Yang <richardw.yang@...ux.intel.com>,
n-horiguchi@...jp.nec.com, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] mm/memory-failure.c: not necessary to recalculate
hpage
On Wed, Nov 20, 2019 at 04:07:38PM +0100, David Hildenbrand wrote:
>On 18.11.19 09:20, Wei Yang wrote:
>> hpage is not changed.
>>
>> Signed-off-by: Wei Yang <richardw.yang@...ux.intel.com>
>> ---
>> mm/memory-failure.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 392ac277b17d..9784f4339ae7 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1319,7 +1319,6 @@ int memory_failure(unsigned long pfn, int flags)
>> }
>> unlock_page(p);
>> VM_BUG_ON_PAGE(!page_count(p), p);
>> - hpage = compound_head(p);
>> }
>> /*
>>
>
>I am *absolutely* no transparent huge page expert (sorry :) ), but won't the
>split_huge_page(p) eventually split the compound page, such that
>compound_head(p) will return something else after that call?
>
ok, you may get some point. I lost some concentration here.
Thanks
>--
>
>Thanks,
>
>David / dhildenb
--
Wei Yang
Help you, Help me
Powered by blists - more mailing lists