On 06/06/2017 05:14 AM, Michal Hocko wrote: > On Tue 06-06-17 13:04:36, Chris Wilson wrote: >> Similar in principle to the treatment of get_user_pages, pages that >> i915.ko acquires from shmemfs are not immediately reclaimable and so >> should be excluded from the mm accounting and vmscan until they have >> been returned to the system via shrink_slab/i915_gem_shrink. By moving >> the unreclaimable pages off the inactive anon lru, not only should >> vmscan be improved by avoiding walking unreclaimable pages, but the >> system should also have a better idea of how much memory it can reclaim >> at that moment in time. > That is certainly desirable. Peter has proposed a generic pin_page (or > similar) API. What happened with it? I think it would be a better > approach than (ab)using mlock API. I am also not familiar with the i915 > code to be sure that using lock_page is really safe here. I think that > all we need is to simply move those pages in/out to/from unevictable LRU > list on pin/unpining. Yes, very true. I just suggested mlock'ing them because it was the simplest way to get page_evictable() to return true. -- 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>
