Messages in this thread | | | Subject | Re: [PATCH 08/15] sched,fair: simplify timeslice length code | From | Rik van Riel <> | Date | Thu, 29 Aug 2019 12:00:31 -0400 |
| |
On Thu, 2019-08-29 at 16:02 +0200, Vincent Guittot wrote: > On Thu, 29 Aug 2019 at 01:19, Rik van Riel <riel@surriel.com> wrote: > > > What am I overlooking? > > My point is more for task that runs several ticks in a row. Their > sched_slice will be shorter in some cases with your changes so they > can be preempted earlier by other runnable tasks with a lower > vruntime > and there will be more context switch
I can think of exactly one case where the time slice will be shorter with my new code than with the old code, and that is the case where: - A CPU has nr_running > sched_nr_latency - __sched_period returns a value larger than sysctl_sched_latency - one of the tasks is much higher priority than the others - that one task alone gets a timeslice larger than sysctl_sched_latency
With the new code, that high priority task will get a time slice that is a (large) fraction of sysctl_sched_latency, while the other (lower priority) tasks get their time slices rounded up to sysctl_sched_min_granularity.
When tasks get their timeslice rounded up, that will increase the total sched period in a similar way the old code did by returning a longer period from __sched_period.
If a CPU is faced with a large number of equal priority tasks, both the old code and the new code would end up giving each task a timeslice length of sysctl_sched_min_granularity.
What am I missing?
-- All Rights Reversed. [unhandled content-type:application/pgp-signature] | |