Re: [PATCH] mm: Throttle shrinkers harder

[Chris Wilson <chris@chris-wilson.co.uk>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>