On KDM Xorg takes ~30MB RSS, but if I login into KDE it grows up to ~170MB and growing further. For example, now uptime is 2 hours, and: $ ps -C X -o rss RSS 211444 For comparison, on my netbook with 945 chipset Xorg takes ~11MB RSS even with KDE and many apps. Hardware: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Software versions: kernel 2.6.39.3 xf86-video-intel from git master (20110713), build options are: --enable-dri --enable-xvmc --enable-kms-only --enable-sna --disable-debug xorg-server 1.10.3 mesa 7.11rc1 If I should provide any logs or additional info — please ask. Thanks in advance.
kwin leaks memory. C'est la vie. The difference is that before the leak was hidden from top since the leak was only in GPU bo which are attributed against the system and no single process.
(And yes I do get regular bug reports from kwin suffers when they discover their system isn't able to allocate any more GPU bo.)
In both cases, the file to watch is /sys/kernel/debug/dri/0/i915_gem_objects.
(In reply to comment #1) > kwin leaks memory. C'est la vie. I haven't such problem on radeon and intel 945. > The difference is that before the leak was hidden from > top since the leak was only in GPU bo which are attributed > against the system and no single process.
(In reply to comment #3) > In both cases, the file to watch is /sys/kernel/debug/dri/0/i915_gem_objects. $ ls /sys/kernel/debug/ $ How to get it? Maybe there are a kernel option?
For /sys/kernel/debug, you need both CONFIG_DEBUGFS and mount -tdebugfs debug /sys/kernel/debug. I've been running X under memory profiling tools and have yet to find a leak.
The issue wasn't that is was leak per-se, since the memory was always reachable and so confused the memory debuggers. It was just that we were wasting system RAM in order to maintain the cache of GTT space. commit 28c8c5ca14c5b4eab7e2dc58c87050c1019037bb Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 29 16:27:35 2011 +0100 sna: Free the buffers immediately upon release They do not appear to have been leaked per-se, but we end up accumulating the unused buffers. A more complicated solution would be to reallocate the handle for retained buffers so that the GTT region can be reused. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39184 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sorry for late reply. So, it's not a true leak? But can we decrease Xorg memory usage with SNA? With kwin it grows up too 500 Mb, this is sometimes uncimfortable due to RAM limit :) I've tested it with compiz (to exclude kwin impact) — same results, but on a smaller scale. Nothing special, just everyday usage (filemanager, browser, etc). I use recent git snapshot (20111202). There are no memory usage grow with UXA (Xorg takes ~15 Mb RSS, noticed max is 30 Mb). I don't change the state of the bug, but I will be grateful if you reply on this. Thanks in advance.
UXA isn't charged for pixmap memory unlike SNA. The only way to compare both is to watch /sys/kernel/debug/dri/0/i915_gem_objects. However, I can reduce the memory consumption by SNA with the usual trade-off against performance - but if it can avoid swapping.... Just don't expect miracles, and it actually won't reduce RSS just the unaccounted memory. What concerns me most is if we experience memory consumption that cannot be explained as belonging to pixmaps.
The difference of accounting between UXA and SNA notwithstanding, I've made a change to release GPU buffers if they lie idle for a couple of minutes: commit c22197f25bc0419d9f2abfcc978df5ef439feb47 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Dec 9 15:12:03 2011 +0000 sna: Discard bo for idle private pixmaps If a pixmap lies around for a couple of minutes not being used, it is unlikely to be used again in the near future. Reap the GPU buffers of any of those idle pixmaps (copying to a more compact buffer in system memory) in order to free up resources for use elsewhere. Any object that is exposed via DRI is obviously exempt from this reaping. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Can you please try running with this and see how your system fares?
(In reply to comment #10) > Can you please try running with this and see how your system fares? I don't see any significant changes. After five hours Xorg RSS is ~300 Mb without any noticeable decrease.
As I was trying to say, that is expected for a KDE desktop session... (At least in my experience of examining their pixmap usage.)
(In reply to comment #12) > As I was trying to say, that is expected for a KDE desktop session... (At least > in my experience of examining their pixmap usage.) Well, may be. Now memory consumption seems to be stable (at about 300 Mb). Anyway, thanks for your work!
Hmm, I don't know, which commit fixed it, but now Xorg uses about 30-40 Mb RSS, and does not grow. Thank you very much for your great work, graphics is very fast with SNA!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.