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

[Mel Gorman <mgorman@techsingularity.net>]

On Thu, Oct 18, 2018 at 02:19:26PM +0000, Wei Yang wrote:
> 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?
> 

That's memory model specific but in some cases yes, it's accessing
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?
> 

The intent was to avoid multiple page->pfn translations.

> 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?

Yes because the lookup has a different cost

> Becase we get pfn by a simple addition. Which I think no need to cache
> it?
> 

Because SPARSEMEM_VMEMMAP is not always used but also because it's
harmless to cache even in the SPARSEMEM_VMEMMAP case.

-- 
Mel Gorman
SUSE Labs