Quoting Mika Kuoppala (2019-11-26 11:13:27) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > 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! > > I needed n+1 cups of coffee for bouncing between this, code and > the codebase. No harm done unless I start to spam irc in chattyness > due to overdoze. > > ...when the real tip-off is the patch subject! > > Thanks for explaining it through in irc. > > It is obvious now when one does get it but it wasn't > before. So please add few lines to the commit message of what > the excise gives us wrt to future improvements in here. > > something like > "By removing the whitelest dependancy from context our freedom > to chop the big mutex is greatly augmented" Ok. > ..in proper english. Hah, that was far more eloquent than my usual drivel. > What are your thoughts on using nonatomic bitops? Fine. Even a hint of concurrent use of the whitelist is a recipe for a nightmare, so s/set_bit/__set_bit/ is ok. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
