From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Josef Bacik <jbacik@fb.com>
Cc: riel@redhat.com, mingo@redhat.com, peterz@infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE
Date: Thu, 28 May 2015 05:46:38 +0200 [thread overview]
Message-ID: <1432784798.3237.81.camel@gmail.com> (raw)
In-Reply-To: <1432761736-22093-1-git-send-email-jbacik@fb.com>
On Wed, 2015-05-27 at 17:22 -0400, Josef Bacik wrote:
> [ sorry if you get this twice, it seems like the first submission got lost ]
>
> At Facebook we have a pretty heavily multi-threaded application that is
> sensitive to latency. We have been pulling forward the old SD_WAKE_IDLE code
> because it gives us a pretty significant performance gain (like 20%). It turns
> out this is because there are cases where the scheduler puts our task on a busy
> CPU when there are idle CPU's in the system. We verify this by reading the
> cpu_delay_req_avg_us from the scheduler netlink stuff. With our crappy patch we
> get much lower numbers vs baseline.
>
> SD_BALANCE_WAKE is supposed to find us an idle cpu to run on, however it is just
> looking for an idle sibling, preferring affinity over all else. This is not
> helpful in all cases, and SD_BALANCE_WAKE's job is to find us an idle cpu, not
> garuntee affinity. Fix this by first trying to find an idle sibling, and then
> if the cpu is not idle fall through to the logic to find an idle cpu. With this
> patch we get slightly better performance than with our forward port of
> SD_WAKE_IDLE. Thanks,
The job description isn't really find idle. it's find least loaded.
> Signed-off-by: Josef Bacik <jbacik@fb.com>
> Acked-by: Rik van Riel <riel@redhat.com>
> ---
> kernel/sched/fair.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 241213b..03dafa3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4766,7 +4766,8 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f
>
> if (sd_flag & SD_BALANCE_WAKE) {
> new_cpu = select_idle_sibling(p, prev_cpu);
> - goto unlock;
> + if (idle_cpu(new_cpu))
> + goto unlock;
> }
>
> while (sd) {
Instead of doing what for most will be a redundant idle_cpu() call,
perhaps a couple cycles can be saved if you move the sd assignment above
affine_sd assignment, and say if (!sd || idle_cpu(new_cpu)) ?
You could also stop find_idlest_group() at the first completely idle
group to shave cycles off the not fully committed search. It ain't
likely to find a negative load.. cool as that would be ;-)
-Mike
next prev parent reply other threads:[~2015-05-28 3:46 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 21:22 [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE Josef Bacik
2015-05-28 3:46 ` Mike Galbraith [this message]
2015-05-28 9:49 ` Morten Rasmussen
2015-05-28 10:57 ` Mike Galbraith
2015-05-28 11:48 ` Morten Rasmussen
2015-05-28 11:49 ` Mike Galbraith
2015-05-28 10:21 ` Peter Zijlstra
2015-05-28 11:05 ` Peter Zijlstra
2015-05-28 14:27 ` Josef Bacik
2015-05-29 21:03 ` Josef Bacik
2015-05-30 3:55 ` Mike Galbraith
2015-06-01 19:38 ` Josef Bacik
2015-06-01 20:42 ` Peter Zijlstra
2015-06-01 21:03 ` Josef Bacik
2015-06-02 17:12 ` Josef Bacik
2015-06-03 14:12 ` Rik van Riel
2015-06-03 14:24 ` Peter Zijlstra
2015-06-03 14:49 ` Josef Bacik
2015-06-03 15:30 ` Mike Galbraith
2015-06-03 15:57 ` Josef Bacik
2015-06-03 16:53 ` Mike Galbraith
2015-06-03 17:16 ` Josef Bacik
2015-06-03 17:43 ` Mike Galbraith
2015-06-03 20:34 ` Josef Bacik
2015-06-04 4:52 ` Mike Galbraith
2015-06-01 22:15 ` Rik van Riel
2015-06-11 20:33 ` Josef Bacik
2015-06-12 3:42 ` Rik van Riel
2015-06-12 5:35 ` Mike Galbraith
2015-06-17 18:06 ` Josef Bacik
2015-06-18 0:55 ` Mike Galbraith
2015-06-18 3:46 ` Josef Bacik
2015-06-18 4:12 ` Mike Galbraith
2015-07-02 17:44 ` Josef Bacik
2015-07-03 6:40 ` Mike Galbraith
2015-07-03 9:29 ` Mike Galbraith
2015-07-04 15:57 ` Mike Galbraith
2015-07-05 7:17 ` Mike Galbraith
2015-07-06 5:13 ` Mike Galbraith
2015-07-06 14:34 ` Josef Bacik
2015-07-06 18:36 ` Mike Galbraith
2015-07-06 19:41 ` Josef Bacik
2015-07-07 4:01 ` Mike Galbraith
2015-07-07 9:43 ` [patch] " Mike Galbraith
2015-07-07 13:40 ` Josef Bacik
2015-07-07 15:24 ` Mike Galbraith
2015-07-07 17:06 ` Josef Bacik
2015-07-08 6:13 ` [patch] sched: beef up wake_wide() Mike Galbraith
2015-07-09 13:26 ` Peter Zijlstra
2015-07-09 14:07 ` Mike Galbraith
2015-07-09 14:46 ` Mike Galbraith
2015-07-10 5:19 ` Mike Galbraith
2015-07-10 13:41 ` Josef Bacik
2015-07-10 20:59 ` Josef Bacik
2015-07-11 3:11 ` Mike Galbraith
2015-07-13 13:53 ` Josef Bacik
2015-07-14 11:19 ` Peter Zijlstra
2015-07-14 13:49 ` Mike Galbraith
2015-07-14 14:07 ` Peter Zijlstra
2015-07-14 14:17 ` Mike Galbraith
2015-07-14 15:04 ` Peter Zijlstra
2015-07-14 15:39 ` Mike Galbraith
2015-07-14 16:01 ` Josef Bacik
2015-07-14 17:59 ` Mike Galbraith
2015-07-15 17:11 ` Josef Bacik
2015-08-03 17:07 ` [tip:sched/core] sched/fair: Beef " tip-bot for Mike Galbraith
2015-05-28 11:16 ` [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE Mike Galbraith
2015-05-28 11:49 ` Ingo Molnar
2015-05-28 12:15 ` Mike Galbraith
2015-05-28 12:19 ` Peter Zijlstra
2015-05-28 12:29 ` Ingo Molnar
2015-05-28 15:22 ` David Ahern
2015-05-28 11:55 ` Srikar Dronamraju
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=1432784798.3237.81.camel@gmail.com \
--to=umgwanakikbuti@gmail.com \
--cc=jbacik@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).