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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>