Hey, On 2025-07-10 17:20, Sebastian Andrzej Siewior wrote: > On 2025-07-10 18:04:42 [+0300], Ville Syrjälä wrote: >> >> When this was last discussed I suggested that there should be a >> versions of the tracepoint macros that do the sampling outside >> the lock, but that wasn't deemed acceptable for whatever reason. >> I don't even know why the current macros are doing the >> sampling while holding the lock... > > Any objections to me sending the batch and we figure out later how get > the tracepoints for i915 enabled again on RT? > It would be an improvement because you could take a vanilla kernel and > enable PREEMPT_RT and you would only miss the tracepoints while now you > can't enable i915 at all and XE either doesn't compile or spills > warnings at runtime due to the code it shares with i915. > > Sebastian FWIW, I did some quick testing. There should be no need for disabling tracepoints on xe. The uncore lock is for a very specific reason (intel_de.h): * Certain architectures will die if the same cacheline is concurrently accessed * by different clients (e.g. on Ivybridge). Access to registers should * therefore generally be serialised, by either the dev_priv->uncore.lock or * a more localised lock guarding all access to that bank of registers. Since we only support modern platforms on xe there is no need for the uncore lock and the specific error will not trigger. On xe, it only exists to be used in vblank evasion for compatiblity with i915.
