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 <[email protected]> > > > > 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
