Re: Checking page_count(page) in invalidate_complete_page

[Andrew Morton <akpm@osdl.org>]

On Thu, 28 Sep 2006 12:26:36 -0400
Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi Nick-
> 
> Nick Piggin wrote:
> >> The page references I'm noting are:
> >>
> >> 1.  add_to_page_cache_lru  1 -> 2
> >>
> >> 2.  do_generic_mapping_read, released in nfs_do_filldir
> >>
> >> 3.  read_cache_page, released in nfs_readdir
> >>
> >> 4.  pagevec_lookup (from invalidate_inode_pages2_range)  2 -> 3
> >>
> >> The odd thing is some of the pages for the directory are released, so 
> >> they must have a ref count of 2 *after* the pagevec_lookup.  Looks 
> >> like more investigation is needed.
> > 
> > 
> > Well they could get flushed out of the lru add pagevecs which drops 
> > their count. Just to
> > test that theory you could run lru_add_drain_all() at the start of the 
> > invalidate function.
> > That's not going to actually fix the problem, but it might help 2.6.18 
> > limp along when
> > combined with some other work.
> 
> I've verified that the pages that fail to be invalidated are indeed 
> languishing in the per-CPU lru-add pagevec.  Adding a call to 
> lru_add_drain_all() to the invalidate_inode_pages2() path does fix the 
> NFS readdir problem.
> 
> I think a call to lru_add_drain_all() belongs in both the 
> invalidate_inode_pages() and the invalidate_inode_pages2() path.  Do you 
> agree?

Yes.  But the page-pinned-by-vmscan scenario which you earlier identified
can still happen, I believe.

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