aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
diff options
context:
space:
mode:
authorPeter Zijlstra <[email protected]>2025-09-17 10:03:20 +0000
committerPeter Zijlstra <[email protected]>2025-09-25 07:51:50 +0000
commita3a70caf7906708bf9bbc80018752a6b36543808 (patch)
tree59039c38fa935f8a4c5fc9454ffa0d134cbb97cf /drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
parentsched/deadline: Fix dl_server getting stuck (diff)
downloadkernel-a3a70caf7906708bf9bbc80018752a6b36543808.tar.gz
kernel-a3a70caf7906708bf9bbc80018752a6b36543808.zip
sched/deadline: Fix dl_server behaviour
John reported undesirable behaviour with the dl_server since commit: cccb45d7c4295 ("sched/deadline: Less agressive dl_server handling"). When starving fair tasks on purpose (starting spinning FIFO tasks), his fair workload, which often goes (briefly) idle, would delay fair invocations for a second, running one invocation per second was both unexpected and terribly slow. The reason this happens is that when dl_se->server_pick_task() returns NULL, indicating no runnable tasks, it would yield, pushing any later jobs out a whole period (1 second). Instead simply stop the server. This should restore behaviour in that a later wakeup (which restarts the server) will be able to continue running (subject to the CBS wakeup rules). Notably, this does not re-introduce the behaviour cccb45d7c4295 set out to solve, any start/stop cycle is naturally throttled by the timer period (no active cancel). Fixes: cccb45d7c4295 ("sched/deadline: Less agressive dl_server handling") Reported-by: John Stultz <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: John Stultz <[email protected]>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c')
0 files changed, 0 insertions, 0 deletions