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 <mgor...@techsingularity.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