Re: Checking page_count(page) in invalidate_complete_page

Chuck Lever
2006-09-29T20:34:57Z

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?