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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
