Re: [PATCH] mm: get pfn by page_to_pfn() instead of save in page->private

From: Wei Yang <richard.weiyang@gmail.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Wei Yang <richard.weiyang@gmail.com>,
	akpm@linux-foundation.org, mhocko@suse.com, linux-mm@kvack.org
Subject: Re: [PATCH] mm: get pfn by page_to_pfn() instead of save in page->private
Date: Thu, 18 Oct 2018 14:19:26 +0000	[thread overview]
Message-ID: <20181018141926.zjiebfjcodthvagg@master> (raw)
In-Reply-To: <20181018133917.GO5819@techsingularity.net>

On Thu, Oct 18, 2018 at 02:39:17PM +0100, Mel Gorman wrote:
>On Thu, Oct 18, 2018 at 09:04:29PM +0800, Wei Yang wrote:
>> This is not necessary to save the pfn to page->private.
>> 
>> The pfn could be retrieved by page_to_pfn() directly.
>> 
>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>
>page_to_pfn is not free which is why it's cached.
>

Hi, Mel

Thanks for your response.

Not free means the access to mem_section?

I have thought about the cache thing, so we assume the list is not that
long, and the cache could hold those page->private for the whole loop?

In my understand, it the cache has limited size, if more data accessed
the cache will be overwritten.

And another thing is:

In case of CONFIG_SPARSEMEM_VMEMMAP, would this be a little different?
Becase we get pfn by a simple addition. Which I think no need to cache
it?

Well, let me take a chance to say thanks to all, Mel, Michael and
Matthew. Hope my silly question won't bother you too much. :-)

>-- 
>Mel Gorman
>SUSE Labs

-- 
Wei Yang
Help you, Help me