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:

> > And AFAIK your patch relies on only migrating pages with mapcount = 0. In 
> > that case I think you can call the migration functions directly without 
> > having to unmap. I thought this would actually be better for your case.
> 
> This only occurs if I find a cached, "misplaced" page in the fault path 
> with mapcount==0.  But the fault path does add another ref on lookup,
> so the refcounts are all one higher in this case.

I send you a set of patches that split migrate_pages(). Maybe that is what 
you are looking for?

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?

> > No. The mapping may have been removed and this check is necessary to not 
> > migrate a page that is already gone.
> 
> OK  I couldn't see how a page could be removed from its mapping while
> we hold it locked.  I'll look closer...

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.


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