Quoting Michal Hocko (2017-06-06 13:14:18) > 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. With respect to i915, we may not be the sole owner of the page at the point where we call shmem_read_mapping_page_gfp() as it can mmapped or accessed directly via the mapping internally. It is just at this point we know that the page will not be returned to the system until we have finished using it with the GPU. An API that didn't assume the page was locked or require exclusive ownership would be needed for random driver usage like i915.ko -Chris -- 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
