On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote: > On 04/24/2014 08:39 AM, Chris Wilson wrote: > > On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote: > >> Is it possible that there's still a get_page() reference that's holding > >> those pages in place from the graphics code? > > > > Not from i915.ko. The last resort of our shrinker is to drop all page > > refs held by the GPU, which is invoked if we are asked to free memory > > and we have no inactive objects left. > > How sure are we that this was performed before the OOM? Only by virtue of how shrink_slabs() works. Thanks for the pointer to register_oom_notifier(), I can use that to make sure that we do purge everything from the GPU, and do a sanity check at the same time, before we start killing processes. > Also, forgive me for being an idiot wrt the way graphics work, but are > there any good candidates that you can think of that could be holding a > reference? I've honestly never seen an OOM like this. Here the only place that we take a page reference is in i915_gem_object_get_pages(). We do this when we first bind the pages into the GPU's translation table, but we only release the pages once the object is destroyed or the system experiences memory pressure. (Once the GPU touches the pages, we no longer consider them to be cache coherent with the CPU and so migrating them between the GPU and CPU requires clflushing, which is expensive.) Aside from CPU mmaps of the shmemfs filp, all operations on our graphical objects should lead to i915_gem_object_get_pages(). However not all objects are recoverable as some may be pinned due to hardware access. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>