[Intel-gfx] [PATCH 1/2] drm/i915/gem: Excise the per-batch whitelist from the context

Chris Wilson chris at chris-wilson.co.uk
Tue Nov 26 14:43:39 UTC 2019


Quoting Joonas Lahtinen (2019-11-26 14:38:00)
> Quoting Chris Wilson (2019-11-25 17:27:09)
> > One does not lightly add a new hidden struct_mutex dependency deep within
> > the execbuf bowels! The immediate suspicion in seeing the whitelist
> > cached on the context, is that it is intended to be preserved between
> > batches, as the kernel is quite adept at caching small allocations
> > itself. But no, it's sole purpose is to serialise command submission in
> > order to save a kmalloc on a slow, slow path!
> 
> When memory pressure increases, it could be the pre-existing clients
> that that fail to allocate the jumplist and start failing instead of
> the new ones...

Sure, doesn't seem like a big issue since any new allocation (such as a
request!!!) may fail.
 
> But if you think many other places will fall apart before that happens,
> feel free to make it dynamic.

I could also argue that unnecessarily caching whitelists in idle
contexts would lead to more oom :)

There is a case that if the malloc cache is slow, or if we need to
fallback to vmalloc, then we should look at a small local cache (on the
engine?).

The good news is that mesa is complaining about 4.19 hitting ENOMEM with
context-create, so we know that at some point they will complain at any
kmalloc if it fails. (But 4.19 -- why even ask me!!!)
-Chris


More information about the Intel-gfx mailing list