[Bug 106136] New: i915 hides gigabytes of memory usage from rest of the system

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106136

            Bug ID: 106136
           Summary: i915 hides gigabytes of memory usage from rest of the
                    system
           Product: DRI
           Version: DRI git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: eero.t.tamminen at intel.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org
     i915 platform: ALL

This is follow up for bug 106106, where X server leaks gigabytes of dirty
memory, which gets swapped out until swap fills completely, and that doesn't
show up anywhere else than in debugfs (if one knows where to look into) &
/proc/meminfo SwapFree value.

I think this has several problems:

* It's (mostly) process specific memory usage that isn't visible in /proc like
rest of memory usage.  Even slab and vmalloc usage is visible in /proc, so GEM
object memory usage should be there too, not just in debugfs

* As a result, huge memory leakage can go completely unnoticed if developer
just has enough memory on his own machine.  Causes for such problems get harder
to track down, the longer it takes to detect what is the actual issue

* This memory doesn't seem to be taken into account when kernel calculates
process OOM score (kernel killed most of my other processes instead of X)

* I assume this memory usage also avoids normal memory usage limits (e.g.
cgroups).  Nasty process is free to cause gigs of GEM object usage, so that
other processes get restricted & OOM killed, and device slowed down by
swapping, without it itself being caught out

I guess solving this requires GEM API through which i915 reports its memory
usage, and it's GEM responsibility to provide that information where
appropriate.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180419/c3cfafc4/attachment.html>