Re: Checking page_count(page) in invalidate_complete_page

Nick Piggin
2006-09-29T00:37:00Z

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