Re: Checking page_count(page) in invalidate_complete_page

[Chuck Lever <chuck.lever@oracle.com>]

Nick Piggin wrote:
> Chuck Lever wrote:
> 
>> Andrew Morton wrote:
>>
>>> lru_add_drain_all() is a nasty, hacky, not-exported-to-modules 
>>> thing.  It
>>> equates to lru_add_drain() if !CONFIG_NUMA.
>>
> 
> It should drain on all CPUs though, I can't remember why it doesn't.
> Not that I disagree that throwing IPIs around is a hack ;)
 >
>>> Sigh, we're not getting there, are we?
>>>
>>> I'm still thinking we add invalidate_complete_page2() to get us out of
>>> trouble and park the problem :(.  That'd be a good approach for 
>>> 2.6.18.x,
>>> which I assume is fairly urgent.
>>
>>
>> Choosing which fix to include is above my pay grade.  Both of these 
>> proposals address the NFS readdir cache invalidation problem.
>>
>> But it seems like there is a real problem here -- the pages that are 
>> waiting to be added the LRU will always have a page count that is too 
>> high for invalidate_inode_pages to work on them.

One option that hasn't been entertained is to remove the "batched LRU
add" logic all together.  Just gut lru_cache_add -- it should send
pages immediately to be added to the LRU list.  This is a bit slower, 
but it fixes the invalidation problems, and makes the icky 
lru_add_drain_all() a no-op.

Note that lru_add_drain_all() would have to be called much more often if 
it is called from the inode invalidation logic... So, which is more 
overhead, adding a page to the LRU at a time, or draining the per-CPU 
LRU pagevecs all the time?

> If you do the lru_add_drain_all, then the vmscan problem should be probably
> mostly fixable by detecting failure, waiting, and retrying a few times.

Why shouldn't invalidate_complete_pages() do that?

> After that, making an invalidate_complete_page2 ignore the page count or
> dirty status would only save you from a very small number of cases, and 
> they
> would be likely to be a data loss / corruption case.
> 
> OTOH, we haven't had many complaints before, so for 2.6.18, an
> invalidate_complete_page2 may indeed be the best option?

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