Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running

[Mel Gorman]

On Mon, Sep 27, 2021 at 04:19:00PM +0200, Vincent Guittot wrote:
> On Mon, 27 Sept 2021 at 13:17, Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Sep 23, 2021 at 02:41:06PM +0200, Vincent Guittot wrote:
> > > On Thu, 23 Sept 2021 at 11:22, Mike Galbraith <efault@xxxxxx> wrote:
> > > >
> > > > On Thu, 2021-09-23 at 10:40 +0200, Vincent Guittot wrote:
> > > > >
> > > > > a 100us value should even be enough to fix Mel's problem without
> > > > > impacting common wakeup preemption cases.
> > > >
> > > > It'd be nice if it turn out to be something that simple, but color me
> > > > skeptical.  I've tried various preemption throttling schemes, and while
> > >
> > > Let's see what the results will show. I tend to agree that this will
> > > not be enough to cover all use cases and I don't see any other way to
> > > cover all cases than getting some inputs from the threads about their
> > > latency fairness which bring us back to some kind of latency niceness
> > > value
> > >
> >
> > Unfortunately, I didn't get a complete set of results but enough to work
> > with. The missing tests have been requeued. The figures below are based
> > on a single-socket Skylake machine with 8 CPUs as it had the most set of
> > results and is the basic case.
> >
> > The reported kernels are
> >
> > vanilla:                        vanilla 5.15-rc1
> > sched-scalewakegran-v2r4:       My patch
> > sched-moveforward-v1r1:         Vincent's patch
> 
> I imagine that this is the results for the 1st version which scales
> with the number of CPUs
> 

Yes, the v1r5 results were incomplete and had to be requeued.

-- 
Mel Gorman
SUSE Labs