Aren't the sendfile() pages in the page cache, and normally taken
off LRU at the same time as removed from page cache, in shrink_cache?
The exception being when the file is truncated while it is being sent,
and buffers busy, so left behind on LRU by truncate_complete_page?
That's not a common case, nor were __free_pages_ok PageLRU BUG
reports on 2.4.14 to 2.4.17 common: most definitely a case that
needs to be handled correctly, but not common.
But I know very little of sendfile(), please correct me.
> > I was proposing we revert to distinguishing page_cache_release
> > from put_page, page_cache_release doing the lru_cache_del; and
> > I'd like to add my in_interrupt() BUG() there for now, just as
> > a sanity check. You are proposing that we keep the current,
> > post-Ben, structure of doing it in __free_pages_ok if possible.
>
> So how exactly would pages be freed ?
>
> You still need to do the check of whether the page can
> be freed somewhere.
I imagined (not yet tried) in shrink_cache, something like:
/*
* In exceptional cases, a page may still be on an
* LRU when it is "freed"; and it would not be possible
* to remove it from LRU at interrupt time: clean up here.
*/
if (unlikely(!page_count(page))) {
page_cache_get(page);
__lru_cache_del(page);
page_cache_release(page);
continue;
}
(Using page_cache_get+page_cache_release instead of get_page+put_page
merely because page_cache_whatever is the local dialect in this module.
But over in unmap_kiobuf I ought to revert from page_cache_release to
put_page, in case it can be called at interrupt time, as Ben implied.)
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/