On Tue, Apr 23, 2013 at 03:00:08PM -0700, Andrew Morton wrote: > That should fix things for now. Although it might be better to just do > > mark_page_accessed(page); /* to SetPageReferenced */ > lru_add_drain(); /* to SetPageLRU */ > > Because a) this was too early to decide that the page is > super-important and b) the second touch of this page should have a > mark_page_accessed() in it already. The question is do we really want to put lru_add_drain() into the ext4 file system code? That seems to pushing some fairly mm-specific knowledge into file system code. I'll do this if I have to do, but wouldn't be better if this was pushed into mark_page_accessed(), or some other new API was exported by the mm subsystem? > At present the code decides up-front which LRU the lru_add_pvecs page > will eventually be spilled onto. That's a bit strange and I wonder why > we did it that way. Why not just have a single (per-cpu) magazine of > pages which are to go onto the LRUs, and decide *which* LRU that will > be at the last possible moment? And this is why it seems strange that fs code should need or should want to put something as mm-implementation dependent into their code paths. At minimum, if we do this, we'll want to put some explanatory comments so that later, people won't be asking, what the !@#@?!? are the ext4 people calling lru_add_drain() here? - Ted -- 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
