Am Donnerstag, dem 29.10.2026 um 11:28 +0100 schrieb Philipp Stanner: > On Thu, 2026-10-29 at 11:23 +0100, Lucas Stach wrote: > > Hi Philipp, hi Christian, > > Jo Lucas > > > > > Am Donnerstag, dem 29.10.2026 um 10:55 +0100 schrieb Philipp Stanner: > > […] > > > I think we would all be interested in the actual use-case that's > > sensitive to this kind of latency. > > Me too. > > Let me use this opportunity to stress that in the future, in DRM, > whenever we have [to accept] a racy "optimization", both commit > messages and code comments must document why it exists and who > requested it with what proof. > I don't fully agree that this is a racy optimization. To me it seems the most critical issue here is that "fence is signaled" is under specified.
Does it purely mean that the actual hardware operation that the fence is guarding is done? In that case the current implementation is fine, as the bit is only set after the HW told us that it is done. This is the interpretation I would assume was the original intent behind the current implementation. Does it mean that the hardware is done and all registered callbacks have been run, even if the actual work is done in a (indefinitely) deferred worker? You mentioning explosions caused by the pure signal state check outside the lock would imply that some consumers of the fence took the signaled state to mean this interpretation. > Would save us lots of time when those things are discussed >5 years > later. > > > > > However, I wonder if this is even an issue anymore with the lock > > inlined into the fence structure. > > Almost no one uses inline-lock so far. So unfortunately, we might > regress old drivers, maybe. > > But sounds as if you're in favor of phasing the locklessness out :) > I'm in favor of ripping out hard to reason optimizations if they turn out to not provide any optimization after all. However, before going in either direction we need to clarify the fence signal state interface. Either we keep the (in my interpretation) original intent of the signal state only telling about HW progress state and thus declare some current uses as wrong usage of the interface, which need to be fixed. Or we need to include the SW callbacks too, but then your current lock approach only guards against code directly executed in the callback functions. If the implementation of the callback defers anything to a worker this may still be racy. And that's also my criticism to this patchset now that I thought a bit more about this: by simply putting things under the lock you serialized more of the SW state without actually better defining the guarantees that this changed fence interface provides or doesn't provide to the consumers. Regards, Lucas
