<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> <div class="moz-text-html" lang="x-western">Since there're a lot of memory leak related issues happened in these days. We'd like to enhance our tests to fill the gap in our validation. Where're some thoughts come out after a few days' investigation. In all, graphics related memory usage issue can fall into following categories: 1.usual user space memory a. invalid access b. memory leak 2. graphics memory a. invalid graphics memory access b. graphics memory leak c. over-all graphics memory manager policy Analysis: 1.[ab]: usual malloc/mmap 2.a: valgrind will misreport many this kind of issues, since graphics memory is mapped by ioctl, which can't be detected by valgrind. 2.b: valgrind has no way to know if a graphics memory object is created or destroyed. GEM manages graphics memory objects by object handle and reference count. 2.c: It may impact user's experience. for example, if graphics memory manager takes too much system memory. It may impact system performance. Solutions: 1.[ab]: covered by valgrind by default. 2.a: we can patch libdrm to notify valgrind about the graphics memory map/unmap. 2.b: we can patch libdrm to notify valgrind about the graphics memory creation/destruction. 2.c: There's no good way to track if graphics takes too much memory. This check still need to be checked manually. Just do a bunch of operations, and checks memory usage is feasible. More considerations: In order to catch those memory leaks, we need to run Xserver or 2D/3D application executing various operation with valgrind. Since memory leak may not jump out itself. It only happens in some code path. In other words, we may not be possible to catch all those, but can try to make sure usual operation won't has this kind of issue. And since X is a client/server model. so: 1. We need to detect if client applications has graphics memory leak. 2. We need to detect if XServer has memory leak: this is targeting operation like VT switch, xrandr operation The patch for libdrm have performance impact, so we can't always apply it. run X or App with valgrind is also much slower than usual. So we have to rebuilt libdrm every time before we want to detect graphics memory issue. Tests could be designed (We could patch libdrm, and recover it after we're done in our daily test): daily test could be designed to catch 1.[ab], 2.[ab] targeting X server: we can do VT switch, various xrandr operation, XVideo. daily test could be designed to catch 1.[ab], 2.[ab] targeting application: we can run 3D apps manual test could be done as P2 test in our RC cycle to catch 2.c The patch of libdrm for testing is attached. You'll need valgrind-devel installed to compile it. Any comments, or more ideas? Thanks --Shuang </div> <pre wrap=""> <hr size="4" width="90%"></pre> </body> </html>