Ed Tomlinson wrote:

This seems to have been missed:

Still thinking about it.

Linus Torvalds wrote:

quoted

In article [ref],
Andrew Morton  [off-list ref] wrote:

quoted

What I'm inclined to do there is to change __page_cache_release()
to not attempt to free the page at all.  Just let it sit on the
LRU until page reclaim encounters it.  With the anon-free-via-pagevec
patch, very, very, very few pages actually get their final release in
__page_cache_release() - zero on uniprocessor, I expect.

If you do this, then I would personally suggest a conceptually different
approach: make the LRU list count towards the page count.  That will
_automatically_ result in what you describe - if a page is on the LRU
list, then "freeing" it will always just decrement the count, and the
_real_ free comes from walking the LRU list and considering count==1 to
be trivially freeable.

That way you don't have to have separate functions for releasing
different kinds of pages (we've seen how nasty that was from a
maintainance standpoint already with the "put_page vs
page_cache_release" thing).

Ehh?

If every structure locks before removing its reference (ie before testing and/or
removing a lru reference we take zone->lru_lock, for slabs take cachep->spinlock
etc)  Its a bit of an audit task to make sure the various locks are taken (and
documented) though.

By leting the actual free be lazy as Linus suggests things should simplify nicely.

Well we wouldn't want to leave tons of free pages on the LRU - the
VM would needlessly reclaim pagecache before finding the free pages.  And
higher-order page allocations could suffer.

If we go for explicit lru removal in truncate and zap_pte_range
then this approach may be best.  Still thinking about it.
--
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/