From: Rik van Riel <riel@redhat.com>
To: Jason Low <jason.low2@hp.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>,
Thomas Gleixner <tglx@linutronix.de>,
Paul Turner <pjt@google.com>, Alex Shi <alex.shi@intel.com>,
Preeti U Murthy <preeti@linux.vnet.ibm.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Namhyung Kim <namhyung@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>, Mel Gorman <mgorman@suse.de>,
aswin@hp.com, scott.norton@hp.com, chegu_vinod@hp.com,
Peter Portante <pportant@redhat.com>,
Larry Woodman <lwoodman@redhat.com>
Subject: Re: [RFC] sched: Limit idle_balance() when it is being used too frequently
Date: Tue, 16 Jul 2013 15:27:28 -0400 [thread overview]
Message-ID: <51E59EA0.6060209@redhat.com> (raw)
In-Reply-To: <1374002463.3944.11.camel@j-VirtualBox>
On 07/16/2013 03:21 PM, Jason Low wrote:
> When running benchmarks on an 8 socket 80 core machine with a 3.10 kernel,
> there can be a lot of contention in idle_balance() and related functions.
> On many AIM7 workloads in which CPUs go idle very often and idle balance
> gets called a lot, it is actually lowering performance.
>
> Since idle balance often helps performance (when it is not overused), I
> looked into trying to avoid attempting idle balance only when it is
> occurring too frequently.
>
> This RFC patch attempts to keep track of the approximate "average" time between
> idle balance attempts per CPU. Each time the idle_balance() function is
> invoked, it will compute the duration since the last idle_balance() for
> the current CPU. The avg time between idle balance attempts is then updated
> using a very similar method as how rq->avg_idle is computed.
>
> Once the average time between idle balance attempts drops below a certain
> value (which in this patch is sysctl_sched_idle_balance_limit), idle_balance
> for that CPU will be skipped. The average time between idle balances will
> continue to be updated, even if it ends up getting skipped. The
> initial/maximum average is set a lot higher though to make sure that the
> avg doesn't fall below the threshold until the sample size is large and to
> prevent the avg from being overestimated.
>
> This change improved the performance of many AIM7 workloads at 1, 2, 4, 8
> sockets on the 3.10 kernel. The most significant differences were at
> 8 sockets HT-enabled. The table below compares the average jobs per minute
> at 1100-2000 users between the vanilla 3.10 kernel and 3.10 kernel with this
> patch. I included data for both hyperthreading disabled and enabled. I used
> numactl to restrict AIM7 to run on certain number of nodes. I only included
> data in which the % difference was beyond a 2% noise range.
Reviewed-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
next prev parent reply other threads:[~2013-07-16 19:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 19:21 [RFC] sched: Limit idle_balance() when it is being used too frequently Jason Low
2013-07-16 19:27 ` Rik van Riel [this message]
2013-07-16 20:20 ` Peter Zijlstra
2013-07-16 22:48 ` Jason Low
2013-07-17 7:25 ` Peter Zijlstra
2013-07-17 7:48 ` Peter Zijlstra
2013-07-17 8:11 ` Jason Low
2013-07-17 9:39 ` Peter Zijlstra
2013-07-17 15:59 ` Jason Low
2013-07-17 16:18 ` Peter Zijlstra
2013-07-17 17:51 ` Rik van Riel
2013-07-17 18:01 ` Peter Zijlstra
2013-07-17 18:48 ` Jason Low
2013-07-18 4:02 ` Jason Low
2013-07-18 9:32 ` Peter Zijlstra
2013-07-18 11:59 ` Rik van Riel
2013-07-18 12:15 ` Srikar Dronamraju
2013-07-18 12:35 ` Peter Zijlstra
2013-07-18 13:06 ` Srikar Dronamraju
2013-07-18 19:06 ` Jason Low
2013-07-19 18:37 ` Peter Zijlstra
2013-07-19 19:15 ` Jason Low
2013-07-18 12:12 ` Srikar Dronamraju
2013-07-18 19:03 ` Jason Low
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=51E59EA0.6060209@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=aswin@hp.com \
--cc=chegu_vinod@hp.com \
--cc=efault@gmx.de \
--cc=jason.low2@hp.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=pportant@redhat.com \
--cc=preeti@linux.vnet.ibm.com \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
/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.