All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Jason Low <jason.low2@hp.com>
Cc: mingo@redhat.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, efault@gmx.de, pjt@google.com,
	preeti@linux.vnet.ibm.com, akpm@linux-foundation.org,
	mgorman@suse.de, riel@redhat.com, aswin@hp.com,
	scott.norton@hp.com
Subject: Re: [PATCH v4 2/3] sched: Consider max cost of idle balance per sched domain
Date: Mon, 2 Sep 2013 12:24:46 +0530	[thread overview]
Message-ID: <20130902065446.GV1720@linux.vnet.ibm.com> (raw)
In-Reply-To: <1377806736-3752-3-git-send-email-jason.low2@hp.com>

* Jason Low <jason.low2@hp.com> [2013-08-29 13:05:35]:

> +	u64 curr_cost = 0;
> 
>  	this_rq->idle_stamp = rq_clock(this_rq);
> 
> -	if (this_rq->avg_idle < sysctl_sched_migration_cost)
> +	if (this_rq->avg_idle < this_rq->max_idle_balance_cost)
>  		return;
> 

Since max_idle_balance_cost includes the cost of balances across all
domains. Can the cost of balance at a higher domain being higher result
in not doing load balance at a lower level?

Shouldnt the check below for sd->max_newidle_lb_cost mean that we can
actually do away with this check.

>  	/*
> @@ -5299,14 +5300,29 @@ void idle_balance(int this_cpu, struct rq *this_rq)
>  	for_each_domain(this_cpu, sd) {
>  		unsigned long interval;
>  		int balance = 1;
> +		u64 t0, domain_cost, max = 5*sysctl_sched_migration_cost;
> 
>  		if (!(sd->flags & SD_LOAD_BALANCE))
>  			continue;
> 
> +		if (this_rq->avg_idle < curr_cost + sd->max_newidle_lb_cost)
> +			break;

I am referring to this check in my above comment.

> +
>  		if (sd->flags & SD_BALANCE_NEWIDLE) {
> +			t0 = 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);
> +
> +			domain_cost = sched_clock_cpu(smp_processor_id()) - t0;
> +			if (domain_cost > max)
> +				domain_cost = max;
> +
> +			if (domain_cost > sd->max_newidle_lb_cost)
> +				sd->max_newidle_lb_cost = domain_cost;

If we face a runq lock contention, then domain_cost can go up.
The runq lock contention could be temporary, but we carry the domain
cost forever (i.e till the next reboot).  How about averaging the cost +
penalty for unsuccessful balance.

Something like 
			domain_cost = sched_clock_cpu(smp_processor_id()) - t0;
			if (!pulled_task)
				domain_cost *= 2;
		
			sd->max_newidle_lb_cost += domain_cost;
			sd->max_newidle_lb_cost /= 2;
				
				
Maybe the name could then change to avg_newidle_lb_cost.

> +
> +			curr_cost += domain_cost;
>  		}
> 
-- 
Thanks and Regards
Srikar Dronamraju


  parent reply	other threads:[~2013-09-02  6:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-29 20:05 [PATCH v4 0/3] sched: Limiting idle balance Jason Low
2013-08-29 20:05 ` [PATCH v4 1/3] sched: Reduce overestimating rq->avg_idle Jason Low
2013-09-02  6:36   ` Srikar Dronamraju
2013-08-29 20:05 ` [PATCH v4 2/3] sched: Consider max cost of idle balance per sched domain Jason Low
2013-08-30  9:46   ` Peter Zijlstra
2013-09-02  6:54   ` Srikar Dronamraju [this message]
2013-09-03 21:06     ` Jason Low
2013-08-29 20:05 ` [RFC][PATCH v4 3/3] sched: Periodically decay max cost of idle balance Jason Low
2013-08-30 10:18   ` Peter Zijlstra
2013-08-30 10:29     ` Peter Zijlstra
2013-09-04  6:02       ` Jason Low
2013-09-09 11:44         ` Peter Zijlstra
2013-09-09 20:40           ` Jason Low
2013-09-04  7:10     ` Jason Low
2013-09-09 11:49       ` Peter Zijlstra
2013-09-09 21:07         ` Jason Low
2013-09-10  1:40           ` Mike Galbraith
2013-09-12 10:31 ` [PATCH v4 0/3] sched: Limiting " Peter Zijlstra

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=20130902065446.GV1720@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=efault@gmx.de \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=riel@redhat.com \
    --cc=scott.norton@hp.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.