Re: [PATCH 2/4] sched: Allow a wakee to run on the prev_cpu if it is idle and cache-affine with the waker

[Mel Gorman]

On Mon, Dec 18, 2017 at 11:26:10AM +0100, Peter Zijlstra wrote:
> > Signed-off-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx>
> > ---
> >  kernel/sched/fair.c | 70 ++++++++++++++++++++++++++++++++++++++---------------
> >  1 file changed, 51 insertions(+), 19 deletions(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 4a1f7d32ecf6..392e08b364bd 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -5689,17 +5689,21 @@ static int wake_wide(struct task_struct *p)
> >   * soonest. For the purpose of speed we only consider the waking and previous
> >   * CPU.
> >   *
> > - * wake_affine_idle() - only considers 'now', it check if the waking CPU is (or
> > - *			will be) idle.
> > + * wake_affine_idle() - only considers 'now', it checks if a CPU that is
> > + *			cache-affine with the waker is idle
> > + *
> 
> This bit belongs in the previous patch I'm thinking.
> 

Yes, sorry.

> > + * wake_affine_sync() - only considers 'now', it checks if the waking CPU
> > + *			will be idle. Migrations to a different NUMA node
> > + *			are allowed on the basis that sync wakeups imply
> > + *			shared data between waker and wakee.
> 
> And it would be nice if we can rework the return value thing in a
> separate patch from adding that affine_sync thing, and then munge your
> 3rd patch along wiht the patch that introduces it.
> 

I can do that. I also noticed that there was an error in wake_affine_idle
in the version I sent. It'll be corrected and retested.

> Did you run these patches on more than just dbench? In specific I
> suppose the schbench stuff from facebook would be interesting. Also that
> NAS-lu benchmark.
> 

A battery of tests including netperf streaming, netperf rr, sockperf,
hackbench (various configs), pipetest, pgbench, siege, tbench, kernel
building and some shellscript intensive workloads. schbench and NAS were
not included but I'll do that before posting a new revision.

Thanks

-- 
Mel Gorman
SUSE Labs