Re: [PATCH 4/7] PM cleanup: Drop nr_refs in remove_references()

[Christoph Lameter <clameter@sgi.com>]

On Mon, 1 May 2006, Lee Schermerhorn wrote:

> > You only need one additional refcount to hold the page. This is the same 
> > as in the case of migrate_pages(). Where does the second refcount come from?
> 
> One from the cache [where I find the page on fault], one from
> find_get_page().

The function alrady considers the reference from mapping. The 
find_get_page() ref is basically the same that isolate_lru_page() takes.

> Plus 1 from page_private(page) buf refs, if any.  Also, to match the

That is also considered in the function.

> page
> state for direct migration, I isolate the page from the lru so it can't
> be found, except through the cache, while I'm migrating it; and that
> adds
> yet another ref.  Net is 1 extra ref in the fault path.

Since you already have a ref from find_get_page() I would not think that 
you would not need an additional one from isolate_lru_page().

> > zap_pte_range() can remove a mapcount without obtaining a lock. Hmmm... 
> > Seems to do nothing with the mapping though. Removal of anonymous mappings 
> > are deferred until we reach free_page() so that does not apply. Check the 
> > file I/O functions.
> 
> I did.  Looked like page->mapping only gets NULLed out in 
> [__]remove_from_page_cache().  I backtracked all of the
> refs I could find, and all seemed to hold page lock.  But, again,
> I could have missed some [cscope can lie, as can my eyes].

If there is none then we can completely remove that check. We already 
check for the mapping to be non null earlier.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>