summaryrefslogtreecommitdiff
path: root/include/linux/timerqueue.h
diff options
context:
space:
mode:
authorTvrtko Ursulin <tvrtko.ursulin@igalia.com>2026-04-17 11:37:23 +0100
committerPhilipp Stanner <phasta@kernel.org>2026-04-17 14:43:28 +0200
commitfd177135f0e62344f5d0ad3b12d40f8f7e5cdaab (patch)
treefaefaf95ff04593df14bdf0c2ee5d6ead8a765aa /include/linux/timerqueue.h
parenta58f317c1ca06d213f49612730206ff90eeaacd8 (diff)
drm/sched: Account entity GPU time
To implement fair scheduling we need a view into the GPU time consumed by entities. Problem we have is that jobs and entities objects have decoupled lifetimes, where at the point we have a view into accurate GPU time, we cannot link back to the entity any longer. Solve this by adding a light weight entity stats object which is reference counted by both entity and the job and hence can safely be used from either side. With that, the only other thing we need is to add a helper for adding the job's GPU time into the respective entity stats object, and call it once the accurate GPU time has been calculated. The most convenient place to do that is the free job worker for several reasons. Doing the accounting from the job completion callback would mean a few locks would need to become irq safe and we would also need to worry about out of order completions (via dma_fence_is_signaled calls which we cannot control). In-order completions are critical for GPU time accuracy which is currently adjusted per fence in the free worker and requires looking at the next job in the scheduler pending list. We would also need to add a new lock to protect the scheduler average stats update. In contrast to those complications, having the accounting done from the free worker is serialized by definition and all the above complications are avoided. Downside is there is potential for a time lag between job completions and GPU time being accounted against the entity. Since that is partly alleviated by batch processing the completed job queue, and the scheduling algorithm does not attempt to be completely fair, which would even be rather impossible to achieve in the GPU world with the current DRM scheduler design and hardware with no or poor preemption support, this downside is not considered critical. Plus, in practice the scheduler is also affected by worker scheduling delays from other angles too. Not least being able to promptly feed the GPU with new work. We therefore choose the simple option and can later consider improving upon it if the need arises. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260417103744.76020-9-tvrtko.ursulin@igalia.com
Diffstat (limited to 'include/linux/timerqueue.h')
0 files changed, 0 insertions, 0 deletions