On Tue, 23 Apr 2013, Theodore Ts'o wrote: > On Tue, Apr 23, 2013 at 02:02:37PM +0200, Bernd Schubert wrote: > > > > I just thought we can (mis)use that flag and and add another > > information to the page that it holds meta data. The mm system then > > could use that flag and evict those pages with a lower priority > > compared to other pages. > > Well, the flag I added was to the buffer_head, not to the page, and my > understanding is that the mm folks are very hesitant to add new page > flags, since they are bumping up against the 32 bit limit (on the i386 > platform), and they are trying to keep the struct page structure trim > and svelte. :-) Yes indeed. But luckily this issue seems not to need another page flag. If metadata is useful, it gets used: so mark_page_accessed when it's used should generally do the job; perhaps it's already called on that path, perhaps calls need to be added. Rarely used but nonetheless useful metadata might get pushed out by data. But I don't think we want another page flag, and yet more complicated reclaim policy in mm for that case. If the filesystem knows of such cases, I hope it can find a way to use mark_page_accessed more often on such pages than they are actually accessed, to help retain them. What this thread did bring up was the failure of mark_page_accessed to be fully effective until the page is flushed from pagevec to lru. That remains a good point: something that several would like to fix. For now I stand by what I said before (if you find it effective in practice - I haven't heard back): at the moment you need to mark_page_accessed(page); /* to SetPageReferenced */ lru_add_drain(); /* to SetPageLRU */ mark_page_accessed(page); /* to SetPageActive */ when such a metadata page is first brought in. We all hate that lru_add_drain in the middle, which will exacerbate lru_lock contention. We would love to eliminate the need for most lru_add_drains: I have some ideas which I'm pursuing in odd moments, but I promise nothing. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
