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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Dec 2017 10:56:46 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] sched: Allow a wakee to run on the prev_cpu if it is
 idle and cache-affine with the waker

On Mon, Dec 18, 2017 at 11:26:10AM +0100, Peter Zijlstra wrote:
> > Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>
> > ---
> >  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