Messages in this thread | | | Date | Tue, 17 Jan 2023 09:32:50 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH v4] sched/fair: limit sched slice duration |
| |
On Fri, Jan 13, 2023 at 02:36:13PM +0100, Vincent Guittot wrote: > In presence of a lot of small weight tasks like sched_idle tasks, normal > or high weight tasks can see their ideal runtime (sched_slice) to increase > to hundreds ms whereas it normally stays below sysctl_sched_latency. > > 2 normal tasks running on a CPU will have a max sched_slice of 12ms > (half of the sched_period). This means that they will make progress > every sysctl_sched_latency period. > > If we now add 1000 idle tasks on the CPU, the sched_period becomes > 3006 ms and the ideal runtime of the normal tasks becomes 609 ms. > It will even become 1500ms if the idle tasks belongs to an idle cgroup. > This means that the scheduler will look for picking another waiting task > after 609ms running time (1500ms respectively). The idle tasks change > significantly the way the 2 normal tasks interleave their running time > slot whereas they should have a small impact. > > Such long sched_slice can delay significantly the release of resources > as the tasks can wait hundreds of ms before the next running slot just > because of idle tasks queued on the rq. > > Cap the ideal_runtime to sysctl_sched_latency to make sure that tasks will > regularly make progress and will not be significantly impacted by > idle/background tasks queued on the rq. > > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> > Tested-By: Dietmar Eggemann <dietmar.eggemann@arm.com>
Acked-by: Mel Gorman <mgorman@suse.de>
-- Mel Gorman SUSE Labs
| |