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@xxxxxxxxx> > > > >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
