scx_lavd: Do not set task's time slice to zero at the ops.enqueue() path #1284
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note that at ops.enqueue() path, setting a task's slice to zero is risky because we don't know the exact status of the task, so it could cause a zero time slice error as follows:
[ 8271.001818] sched_ext: ksoftirqd/1[70] has zero slice in pick_task_scx()
The zero slice warning is harmful because the sched_ext core ends up setting the time slice to SCX_SLICE_DFL (20 msec), increasing latency spikes.
Thus, we do not set the time slice to 0 at the ops.enqueue() path and rely on scx_bpf_kick_cpu(SCX_KICK_PREEMPT) all the time. Also, use 1 (instead of 0) as a marker to perform scx_bpf_kick_cpu().
This should solve the following issue:
#1283