From: Srikar Dronamraju <srikar@linux.vnet.ibm.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>,
Rik van Riel <riel@redhat.com>,
aswin@hp.com, scott.norton@hp.com, chegu_vinod@hp.com
Subject: Re: [RFC PATCH v2] sched: Limit idle_balance()
Date: Mon, 22 Jul 2013 12:31:44 +0530 [thread overview]
Message-ID: <20130722070144.GC5138@linux.vnet.ibm.com> (raw)
In-Reply-To: <1374220211.5447.9.camel@j-VirtualBox>
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e8b3350..da2cb3e 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1348,6 +1348,8 @@ ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
> else
> update_avg(&rq->avg_idle, delta);
> rq->idle_stamp = 0;
> +
> + rq->idle_duration = (rq->idle_duration + delta) / 2;
Cant we just use avg_idle instead of introducing idle_duration?
> }
> #endif
> }
> @@ -7027,6 +7029,7 @@ void __init sched_init(void)
> rq->online = 0;
> rq->idle_stamp = 0;
> rq->avg_idle = 2*sysctl_sched_migration_cost;
> + rq->idle_duration = 0;
>
> INIT_LIST_HEAD(&rq->cfs_tasks);
>
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index 75024a6..a3f062c 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -307,6 +307,7 @@ do { \
> P(sched_goidle);
> #ifdef CONFIG_SMP
> P64(avg_idle);
> + P64(idle_duration);
> #endif
>
> P(ttwu_count);
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c61a614..da7ddd6 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5240,6 +5240,8 @@ void idle_balance(int this_cpu, struct rq *this_rq)
> struct sched_domain *sd;
> int pulled_task = 0;
> unsigned long next_balance = jiffies + HZ;
> + u64 cost = 0;
> + u64 idle_duration = this_rq->idle_duration;
>
> this_rq->idle_stamp = this_rq->clock;
>
> @@ -5256,14 +5258,31 @@ void idle_balance(int this_cpu, struct rq *this_rq)
> for_each_domain(this_cpu, sd) {
> unsigned long interval;
> int balance = 1;
> + u64 this_domain_balance_cost = 0;
> + u64 start_time;
>
> if (!(sd->flags & SD_LOAD_BALANCE))
> continue;
>
> + /*
> + * If the time which this_cpu remains is not lot higher than the cost
> + * of attempt idle balancing within this domain, then stop searching.
> + */
> + if (idle_duration / 10 < (sd->avg_idle_balance_cost + cost))
> + break;
> +
> if (sd->flags & SD_BALANCE_NEWIDLE) {
> + start_time = sched_clock_cpu(smp_processor_id());
> +
> /* If we've pulled tasks over stop searching: */
> pulled_task = load_balance(this_cpu, this_rq,
> sd, CPU_NEWLY_IDLE, &balance);
> +
> + this_domain_balance_cost = sched_clock_cpu(smp_processor_id()) - start_time;
Should we take the consideration of whether a idle_balance was
successful or not?
How about having a per-sched_domain counter.
For every nth unsuccessful load balance, skip the n+1th idle
balance and reset the counter. Also reset the counter on every
successful idle load balance.
I am not sure whats a reasonable value for n can be, but may be we could
try with n=3.
Also have we checked the performance after adjusting the
sched_migration_cost tunable?
I guess, if we increase the sched_migration_cost, we should have lesser
newly idle balance requests.
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2013-07-22 17:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-19 7:50 [RFC PATCH v2] sched: Limit idle_balance() Jason Low
2013-07-19 11:24 ` Preeti U Murthy
2013-07-19 19:28 ` Jason Low
2013-07-21 17:32 ` Preeti U Murthy
2013-07-22 17:42 ` Jason Low
2013-07-22 7:01 ` Srikar Dronamraju [this message]
2013-07-22 18:57 ` Jason Low
2013-07-23 11:03 ` Peter Zijlstra
2013-07-24 7:06 ` Jason Low
2013-07-23 11:06 ` Srikar Dronamraju
2013-07-23 12:05 ` Peter Zijlstra
2013-07-23 12:33 ` Mike Galbraith
2013-07-24 4:24 ` 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=20130722070144.GC5138@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.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=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=preeti@linux.vnet.ibm.com \
--cc=riel@redhat.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.