Re: [RFC PATCH 1/2] sched: Rate limit migrations to 1 per 2ms per task

[Mathieu Desnoyers]

On 9/6/23 04:44, Peter Zijlstra wrote:
> On Tue, Sep 05, 2023 at 05:16:25PM -0400, Mathieu Desnoyers wrote:
> > On 9/5/23 16:28, Tim Chen wrote:
> > > On Tue, 2023-09-05 at 13:11 -0400, Mathieu Desnoyers wrote:
> > > > Rate limit migrations to 1 migration per 2 milliseconds per task. On a
> > > > kernel with EEVDF scheduler (commit b97d64c722598ffed42ece814a2cb791336c6679),
> > > > this speeds up hackbench from 62s to 45s on AMD EPYC 192-core (over 2 sockets).
> > > >
> > > >
> > > >
> > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > > index 479db611f46e..0d294fce261d 100644
> > > > --- a/kernel/sched/core.c
> > > > +++ b/kernel/sched/core.c
> > > > @@ -4510,6 +4510,7 @@ static void __sched_fork(unsigned long clone_flags, struct task_struct *p)
> > > >    	p->se.vruntime			= 0;
> > > >    	p->se.vlag			= 0;
> > > >    	p->se.slice			= sysctl_sched_base_slice;
> > > > +	p->se.next_migration_time	= 0;
> > >
> > > It seems like the next_migration_time should be initialized to the current time,
> > > in case the system run for a long time and clock wrap around could cause problem.
> >
> > next_migration_time is a u64, which should "never" overflow. Other scheduler
> > code comparing with sched_clock() don't appear to care about u64 overflow.
>
> Much code actually considers overflow. We also have monotonicity filters
> where it really matters.

OK, I'll update the patch to consider overflow if we end up going that
route, but for now I'll try an approach based on idle timestamps
instead.

Thanks,

Mathieu


--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com