[Mesa-dev] [PATCH 2/2] i965: Warn for GTT fallbacks when mapping the batch/state buffers.

[Chris Wilson]

Quoting Kenneth Graunke (2017-09-17 15:06:49)
> On Sunday, September 17, 2017 1:58:16 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-09-16 09:31:27)
> > > This shouldn't really happen in practice, but I hit it a couple of times
> > > when running a driver with a bad memory leak.  We may as well hook up
> > > the warning, because if it ever triggers, we'll know something is wrong.
> > 
> > Out of curiosity, the GTT mmap also failed? If you didn't have enough
> > virtual space for one mmap, the other should also fail.
> 
> Oddly, the CPU map failed, but GTT maps continued working for a little
> while.  It did seem strange.  I think maps did eventually quit working
> altogether.
> 
> The leak in this case was when I'd botched the refcounting of the state
> buffer, and just never freed them at all.
> 
> > Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > How important is the requirement to flag GL_NO_MEMORY rather than
> > explode? Even for batch reset, we should still be able to propagate the
> > error back to the context (and cancel the operation to prevent further
> > dismay, or install some dummy).
> > -Chris
> 
> I don't think it's worth doing, personally.  There are just so many ways
> things can go off the rails.  A better option might be to have brw_bufmgr
> dump some VMA from unused BO cache entries, and then retry the map...

It's even worse than that. Something I remembered too late is that if
the mmap fails during pagefault due to ENOMEM, that generates a SIGBUS.
Handling that is not impossible, but it does mean having to trap signals
around every volatile access. Signals and a multithreaded library do not
mix! (The ddx does wrap itself with sigtrap_get()/sigtrap_put(), but
afaict it has to be a decision the client has to make due to the way
signals work.)
-Chris