Messages in this thread |  | | From | Ed Tomlinson <> | Subject | Re: MM patches against 2.5.31 | Date | Mon, 26 Aug 2002 18:09:45 -0400 |
| |
This seems to have been missed:
Linus Torvalds wrote:
> In article <3D6989F7.9ED1948A@zip.com.au>, > Andrew Morton <akpm@zip.com.au> wrote: >> >>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.
comments, Ed Tomlinson - 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/
|  |