diff options
| author | Peter Zijlstra <[email protected]> | 2025-09-17 10:03:20 +0000 |
|---|---|---|
| committer | Peter Zijlstra <[email protected]> | 2025-09-25 07:51:50 +0000 |
| commit | a3a70caf7906708bf9bbc80018752a6b36543808 (patch) | |
| tree | 59039c38fa935f8a4c5fc9454ffa0d134cbb97cf /drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | |
| parent | sched/deadline: Fix dl_server getting stuck (diff) | |
| download | kernel-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_encoders.c')
0 files changed, 0 insertions, 0 deletions
