All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael wang <wangyun@linux.vnet.ibm.com>
To: Mike Galbraith <bitbucket@online.de>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Paul Turner <pjt@google.com>,
	Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true)
Date: Thu, 26 Sep 2013 10:50:17 +0800	[thread overview]
Message-ID: <5243A0E9.4060802@linux.vnet.ibm.com> (raw)
In-Reply-To: <1380099377.8523.9.camel@marge.simpson.net>

On 09/25/2013 04:56 PM, Mike Galbraith wrote:
> On Wed, 2013-09-25 at 09:53 +0200, Peter Zijlstra wrote: 
>> Subject: sched: Avoid select_idle_sibling() for wake_affine(.sync=true)
>> From: Peter Zijlstra <peterz@infradead.org>
>> Date: Wed Sep 25 08:28:39 CEST 2013
>>
>> When a task is the only running task and does a sync wakeup; avoid
>> going through select_idle_sibling() as it doesn't know the current CPU
>> is going to be idle shortly.
>>
>> Without this two sync wakers will ping-pong between CPUs for no
>> reason.
> 
> That will make pipe-test go fugly -> pretty, and help very fast/light
> localhost network, but eat heavier localhost overlap recovery.  We need
> a working (and cheap) overlap detector scheme, so we can know when there
> is enough to be worth going after.
> 
> (I sent you some lmbench numbers offline a while back showing the
> two-faced little <b-word> in action, doing both good and evil)

It seems like the choice between the overhead and a little possibility
to balance the load :)

Like the case when we have:

	core0 sg		core1 sg
	cpu0	cpu1		cpu2	cpu3
	waker	busy		idle	idle

If the sync wakeup was on cpu0, we can:

1. choose cpu in core1 sg like we did usually
   some overhead but tend to make the load a little balance
	core0 sg		core1 sg
	cpu0	cpu1		cpu2	cpu3
	idle	busy		wakee	idle

2. choose cpu0 like the patch proposed
   no overhead but tend to make the load a little more unbalance
	core0 sg		core1 sg
	cpu0	cpu1		cpu2	cpu3
	wakee	busy		idle	idle

May be we should add a higher scope load balance check in wake_affine(),
but that means higher overhead which is just what the patch want to
reduce...

What about some discount for sync case inside select_idle_sibling()?
For example we consider sync cpu as idle and prefer it more than the others?

Regards,
Michael Wang


>> Suggested-by: Rik van Riel <riel@redhat.com>
>> Signed-off-by: Peter Zijlstra <peterz@infradead.org>
>> ---
>>  kernel/sched/fair.c |   10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -3461,6 +3461,16 @@ select_task_rq_fair(struct task_struct *
>>  		if (cpu != prev_cpu && wake_affine(affine_sd, p, sync))
>>  			prev_cpu = cpu;
>>  
>> +		/*
>> +		 * Don't bother with select_idle_sibling() in the case of a sync wakeup
>> +		 * where we know the only running task will soon go away. Going
>> +		 * through select_idle_sibling will only lead to pointless ping-pong.
>> +		 */
>> +		if (sync && prev_cpu == cpu && cpu_rq(cpu)->nr_running == 1) {
>> +			new_cpu = cpu;
>> +			goto unlock;
>> +		}
>> +
>>  		new_cpu = select_idle_sibling(p, prev_cpu);
>>  		goto unlock;
>>  	}
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2013-09-26  2:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25  7:53 [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true) Peter Zijlstra
2013-09-25  8:56 ` Mike Galbraith
2013-09-26  2:50   ` Michael wang [this message]
2013-09-26  3:41     ` Mike Galbraith
2013-09-26  5:12       ` Michael wang
2013-09-26  5:34         ` Mike Galbraith
2013-09-26  6:15           ` Mike Galbraith
2013-09-26  6:32           ` Michael wang
2013-09-26  7:09             ` Mike Galbraith
2013-09-26  7:26               ` Michael wang
2013-09-26  9:58   ` Peter Zijlstra
2013-09-26 10:05     ` Peter Zijlstra
2013-09-26 10:55     ` Paul Turner
2013-09-26 11:16       ` Peter Zijlstra
2013-09-26 11:39         ` Paul Turner
2013-09-26 14:35           ` Peter Zijlstra
2013-09-26 15:43             ` Peter Zijlstra
2013-09-26 13:46     ` Mike Galbraith
2013-09-26 15:09     ` Michael wang
2013-09-26 15:44       ` Peter Zijlstra
2013-09-27  1:19         ` Michael wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5243A0E9.4060802@linux.vnet.ibm.com \
    --to=wangyun@linux.vnet.ibm.com \
    --cc=bitbucket@online.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.