Re: [PATCH v5 0/4] drm/xe/forcewake: add delayed-release optimization

[Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>]

On Thu, Sep 03, 2026 at 04:19:01PM -0700, Bai, Zongyao wrote:
>
>On 9/3/2026 11:59 AM, Umesh Nerlige Ramappa wrote:
>>Hi Zongyao,
>>
>>On Thu, Aug 13, 2026 at 12:06:50AM +0000, Zongyao Bai wrote:
>>>Engine-cycle queries used by tools such as VTune and PTI can arrive in
>>>bursts. Releasing forcewake immediately after every query makes the next
>>>query issue another wake request and wait for its ACK.
>>>
>>>Add an opt-in delayed-release path that keeps an idle forcewake domain
>>>awake for a configurable interval, allowing a subsequent engine-cycle
>>>query to reuse it. Other forcewake users retain the existing immediate
>>>release behavior. The default hold interval is 100 us and can be changed
>>>through configfs before binding the device.
>>>
>>>The series also synchronizes engine-cycle queries with unplug and 
>>>flushes
>>>pending delayed releases before suspend, shutdown, remove, and probe
>>>unwind, ensuring timer callbacks cannot access MMIO after power-off or
>>>teardown.
>>>
>>>On BMG, this reduced the Level Zero timestamp median from approximately
>>>48.5 us to 9.4 us.
>>
>>Can you please add some more info here on what this measurement is 
>>and how this is affecting the VTune/PTI use cases? In other words, 
>>what breaks if we don't have these changes?
>>
>>The purpose of engine_cycles query is just to capture CPU and GPU 
>>timestamps as close to each other as possible and then the user 
>>would use that to map the two timelines in whatever they are trying 
>>to correlate, so I am interested in understanding the use case that 
>>this is improving.
>>
>>Thanks,
>>Umesh
>Hi Umesh,
>
>The main issue without this patch is the latency introduced when the 
>XE forcewake domain goes to sleep immediately after a query completes.
>
>In VTune/PTI workloads, APIs such as zeDeviceGetGlobalTimestamps() may 
>be called at a very high frequency to correlate CPU and GPU timelines. 
>It's not a one time query.
>Since the forcewake domain is released right after the MMIO read, the 
>next query often arrives after only a very short interval and must go 
>through the full forcewake acquisition and MMIO read sequence again.
>On bmg, we measured that this additional forcewake overhead can be 
>around 48.5 µs, even with RC6 disabled.
>

If you could just somehow mention that the numbers are overheads in the 
line below, that would be great.

"On BMG, this reduced the Level Zero timestamp median from approximately
48.5 us to 9.4 us"

Thanks for the details.
Umesh

...