linux-kernel - Re: [PATCH 3/4] sched: Comment on why sync wakeups try to run on the current CPU

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171219202536.vsmlw63apswkwiir@techsingularity.net>
Date:   Tue, 19 Dec 2017 20:25:36 +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 3/4] sched: Comment on why sync wakeups try to run on the
 current CPU

On Tue, Dec 19, 2017 at 08:06:44PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 18, 2017 at 09:43:26AM +0000, Mel Gorman wrote:
> > The sync wakeup logic in wake_affine_idle deserves a short description.
> > 
> > Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>
> > ---
> >  kernel/sched/fair.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 392e08b364bd..95b1145bc38d 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -5737,6 +5737,11 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync)
> >  static int
> >  wake_affine_sync(int this_cpu, int sync)
> >  {
> > +	/*
> > +	 * Consider stacking tasks if it's a sync wakeup and there is only
> > +	 * one task on the runqueue. sync wakesups are expected to sleep
> > +	 * either immediately or shortly after the wakeup.
> > +	 */
> >  	if (sync && cpu_rq(this_cpu)->nr_running == 1)
> >  		return this_cpu;
> >  
> 
> So I don't think this one is over the top -- it went missing from the
> last posting, but I agree with Mike that 4/4 was somewhat dodgy.
> 

I dropped it because I wasn't altering what sync wakeup means any more
and the comment was not that insightful. I've no objection to it being
picked up of course.

> Our SYNC hint does promise the caller will go away 'soon', although I'm
> not sure how many of the current users actually honor that.
> 

How soon matters a little too. I think pipe goes asleep immediately, exit
definitely does.  Networking appears to be soon enough from what I can tell.
I don't think any of the current callers of wake_up_interruptible_sync_poll
are problematic at least.

> In any case, picked up the one new patch, thanks for the giant changelog
> ;-)

Thanks!

-- 
Mel Gorman
SUSE Labs