Re: [PATCH v3 4/6] sched/fair: Limit run to parity to the min slice of enqueued entities

[Madadi Vineeth Reddy <vineethr@linux.ibm.com>]

Hi Vincent,

On 21/07/25 14:41, Vincent Guittot wrote:
> On Sun, 20 Jul 2025 at 12:57, Madadi Vineeth Reddy
> <vineethr@linux.ibm.com> wrote:
>>
>> On 13/07/25 23:47, Madadi Vineeth Reddy wrote:
>>> Hi Vincent, Peter
>>>
>>> On 10/07/25 18:04, Peter Zijlstra wrote:
>>>>
>>>>>> If I set my task’s custom slice to a larger value but another task has a smaller slice,
>>>>>> this change will cap my protected window to the smaller slice. Does that mean my custom
>>>>>> slice is no longer honored?
>>>>>
>>>>> What do you mean by honored ? EEVDF never mandates that a request of
>>>>> size slice will be done in one go. Slice mainly defines the deadline
>>>>> and orders the entities but not that it will always run your slice in
>>>>> one go. Run to parity tries to minimize the number of context switches
>>>>> between runnable tasks but must not break fairness and lag theorem.So
>>>>> If your task A has a slice of 10ms and task B wakes up with a slice of
>>>>> 1ms. B will preempt A because its deadline is earlier. If task B still
>>>>> wants to run after its slice is exhausted, it will not be eligible and
>>>>> task A will run until task B becomes eligible, which is as long as
>>>>> task B's slice.
>>>>
>>>> Right. Added if you don't want wakeup preemption, we've got SCHED_BATCH
>>>> for you.
>>>
>>> Thanks for the explanation. Understood now that slice is only for deadline
>>> calculation and ordering for eligible tasks.
>>>
>>> Before your patch, I observed that each task ran for its full custom slice
>>> before preemption, which led me to assume that slice directly controlled
>>> uninterrupted runtime.
>>>
>>> With the patch series applied and RUN_TO_PARITY=true, I now see the expected behavior:
>>> - Default slice (~2.8 ms): tasks run ~3 ms each.
>>> - Increasing one task’s slice doesn’t extend its single‐run duration—it remains ~3 ms.
>>> - Decreasing one tasks’ slice shortens everyone’s run to that new minimum.
>>>
>>> With this patch series, With NO_RUN_TO_PARITY, I see runtimes near 1 ms (CONFIG_HZ=1000).
>>>
>>> However, without your patches, I was still seeing ~3 ms runs even with NO_RUN_TO_PARITY,
>>> which confused me because I expected runtime to drop to ~1 ms (preempt at every tick)
>>> rather than run up to the default slice.
>>>
>>> Without your patches and having RUN_TO_PARITY is as expected. Task running till it's
>>> slice when eligible.
>>>
>>> I ran these with 16 stress‑ng threads pinned to one CPU.
>>>
>>> Please let me know if my understanding is incorrect, and why I was still seeing ~3 ms
>>> runtimes with NO_RUN_TO_PARITY before this patch series.
>>>
>>
>> Hi Vincent,
>>
>> Just following up on my earlier question: with the patch applied (and RUN_TO_PARITY=true),
>> reducing one task’s slice now clamps the runtime of all tasks on that runqueue to the new
>> minimum.(By “runtime” I mean the continuous time a task runs before preemption.). Could this
>> negatively impact throughput oriented workloads where remaining threads need longer run time
>> before preemption?
> 
> Probably, it is also expected that tasks which have shorter slices,
> don't want to run forever. The shorter runtime will only apply while
> the task is runnable and this task should run 1st or almost and go
> back to sleep so its impact should be small. I agree that if you have
> an always running task which sets its slice to 1ms it will increase
> number of context switch for other tasks which don't have a longer
> slice but we can't do much against that
> 
>>
>> I understand that slice is only for ordering of deadlines but just curious about it's
>> effect in scenarios like this.

Understood, thank you for the clarification. Since fairness is the first priority, I see
that there's not much that can be done in the "always running" case.

Thanks again for the detailed explanation.

Thanks,
Madadi Vineeth Reddy

>>
>> Thanks,
>> Madadi Vineeth Reddy
>>
>>> Thanks,
>>> Madadi Vineeth Reddy
>>