On Thu, Nov 1, 2018 at 10:30 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 11/1/18 5:06 AM, Vovo Yang wrote: > >> mlock() and ramfs usage are pretty easy to track down. /proc/$pid/smaps > >> or /proc/meminfo can show us mlock() and good ol' 'df' and friends can > >> show us ramfs the extent of pinned memory. > >> > >> With these, if we see "Unevictable" in meminfo bump up, we at least have > >> a starting point to find the cause. > >> > >> Do we have an equivalent for i915? Chris helped to answer this question: Though it includes a few non-shmemfs objects, see debugfs/dri/0/i915_gem_objects and the "bound objects". Example i915_gem_object output: 591 objects, 95449088 bytes 55 unbound objects, 1880064 bytes 533 bound objects, 93040640 bytes ... > > AFAIK, there is no way to get i915 unevictable page count, some > > modification to i915 debugfs is required. > > Is something like this feasible to add to this patch set before it gets > merged? For now, it's probably easy to tell if i915 is at fault because > if the unevictable memory isn't from mlock or ramfs, it must be i915. > > But, if we leave it as-is, it'll just defer the issue to the fourth user > of the unevictable list, who will have to come back and add some > debugging for this. > > Seems prudent to just do it now.
