<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Chris,<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On 3 June 2014 16:12, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Mon, Jun 02, 2014 at 02:18:14PM +0100, Sam Jansen wrote:<br>
> Hello intel-gfx,<br>
> I'm working on an application using VA-API for H264 encode+decode, and<br>
> JPEG decode on an Atom E3815. Unfortunately we've hit what I believe is a<br>
> kernel bug, and the "perf top" output is pointing at i915 DRM code.<br>
> After some amount of time running my application, the system will become<br>
> unresponsive (userspace applications get very little CPU, system CPU will<br>
> go up to 80+%), and sometimes the system will appear out of memory for a<br>
> period (the OOM killer is sometimes invoked), even though there is a lot<br>
> of free memory on the system. I noticed this first on kernel 3.14.5, so I<br>
> moved to "drm-intel-nightly", built on Friday (2014-05-30), from<br>
</div>> [1]<a href="http://cgit.freedesktop.org/drm-intel" target="_blank">http://cgit.freedesktop.org/drm-intel</a>. The results are the same.<br>
<div class="">> Using "perf top", I have gathered the following traces showing high system<br>
> CPU at the time when the system was encountering this problem:<br>
<br>
</div>It's a buffer leak in the userspace va-api application. The buffers<br>
appear as cached memory, they are not yet accounted against the<br>
applications that have a reference to them. Look at<br>
/sys/kernel/debug/dri/0/i915_gem_objects for a breakdown of users.<span class=""><font color="#888888"><br></font></span></blockquote><div> </div><div>Thanks for taking the time to respond. I had previously ruled out buffer leaks by using valgrind and similar to track down any user-space leaks -- VA-API buffers have user-space metadata allocated with malloc/calloc, so if you leak these it is fairly easy to track down.</div>
<div><br></div><div>However, given the new knowledge that the memory really is associated with my app, I used divide-and-conquer to eventually track the issue down to my JPEG decoder. I found that due to not updating one bit of state, I was accidentily creating/destroying the surfaces and context every frame. I've fixed that, and my application no longer leaks "cached" kernel memory.</div>
<div><br></div><div>I thought perhaps this is still a real bug, as it looks to me like my application was cleaning up resources correctly. So I've managed to reproduce my results using the "loadjpeg" test application distributed with libva, with only minimal changes: looping to decode the JPEG image many times a second, and cleaning up buffers each iteration. I've no idea if this problem is limited to just the JPEG decoder, but it seemed the simplest test app to hack. When I run this modified version of loadjpeg with a ~720p image, I leak ~40M cached memory/sec, ~100 objects/sec (as shown by i915_gem_objects).</div>
<div><br></div><div>I've attached the patch in case you are interested.</div><div><br></div><div>As an aside, while debugging this, I hit the attached OOPS a couple of times, while running "watch cat /sys/kernel/debug/dri/0/i915_gem_objects".</div>
<div><br></div><div>Cheers,</div><div>Sam</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">
<br>
--<br>
Chris Wilson, Intel Open Source Technology Centre<br>
_______________________________________________<br>
Intel-gfx mailing list<br>
<a href="mailto:Intel-gfx@lists.freedesktop.org">Intel-gfx@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a><br>
</font></span></blockquote></div><br></div></div>