Re: Checking page_count(page) in invalidate_complete_page

[Nick Piggin <nickpiggin@yahoo.com.au>]

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.


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.

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 complains before, so for 2.6.18, an
invalidate_complete_page2 may indeed be the best option?

--

Send instant messages to your online friends http://au.messenger.yahoo.com 

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