Message-ID: <cee2b280-a036-43b5-8ff8-6ec2a0b9356b@linux.ibm.com>
Date: Sun, 20 Jul 2025 16:27:02 +0530
From: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
        juri.lelli@...hat.com, dietmar.eggemann@....com, rostedt@...dmis.org,
        bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com,
        dhaval@...nis.ca, linux-kernel@...r.kernel.org,
        Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
Subject: Re: [PATCH v3 4/6] sched/fair: Limit run to parity to the min slice
 of enqueued entities

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? 

I understand that slice is only for ordering of deadlines but just curious about it's
effect in scenarios like this.

Thanks,
Madadi Vineeth Reddy

> Thanks,
> Madadi Vineeth Reddy

Powered by blists - more mailing lists