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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKfTPtCNkqp87j8mAKbfBS+Pk=YWv9qQf9VE4=AkqPu9YCR=Kw@mail.gmail.com>
Date: Mon, 21 Jul 2025 11:11:44 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
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
Subject: Re: [PATCH v3 4/6] sched/fair: Limit run to parity to the min slice
 of enqueued entities

On Sun, 20 Jul 2025 at 12:57, Madadi Vineeth Reddy
<vineethr@...ux.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.
>
> Thanks,
> Madadi Vineeth Reddy
>
> > Thanks,
> > Madadi Vineeth Reddy
>