<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - i915 hides gigabytes of memory usage from rest of the system" href="https://bugs.freedesktop.org/show_bug.cgi?id=106136#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - i915 hides gigabytes of memory usage from rest of the system" href="https://bugs.freedesktop.org/show_bug.cgi?id=106136">bug 106136</a> from <a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> Eero Tamminen</a> <pre>(In reply to Francesco Balestrieri from <a href="show_bug.cgi?id=106136#c2">comment #2</a>) > This might be a dumb question, but how is it different from <a class="bz_bug_link bz_status_NEW " title="NEW - GEM object leaks with fullscreen programs -> swap fills up + OOM kills within few hours" href="show_bug.cgi?id=106106">bug 106106</a> ? <a class="bz_bug_link bz_status_NEW " title="NEW - GEM object leaks with fullscreen programs -> swap fills up + OOM kills within few hours" href="show_bug.cgi?id=106106">Bug 106106</a> is about horrible X server graphics memory (GEM objects) leakage. To fix that bug, X just needs to free related object when it's done with it. Should be trivial. This bug is about how to detect such leakage and be able control it in processes. I.e. kernel i915 module not providing visibility for graphics memory usage (like happens for all other memory), and lacking means to control/limit processes' usage of this memory in standard ways (out of memory killer, cgroups etc). Fixing this will likely need a lot of talks with upstream, on how that should be solved (API to rest of GEM, /proc/ API...).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>