linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael wang <wangyun@linux.vnet.ibm.com>
To: Alex Shi <alex.shi@linaro.org>,
	mingo@redhat.com, peterz@infradead.org, tglx@linutronix.de,
	daniel.lezcano@linaro.org, vincent.guittot@linaro.org,
	morten.rasmussen@arm.com
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	fengguang.wu@intel.com, linaro-kernel@lists.linaro.org
Subject: Re: [RFC PATCH] sched: find the latest idle cpu
Date: Wed, 15 Jan 2014 13:33:20 +0800	[thread overview]
Message-ID: <52D61DA0.8050206@linux.vnet.ibm.com> (raw)
In-Reply-To: <1389758879-19951-1-git-send-email-alex.shi@linaro.org>

On 01/15/2014 12:07 PM, Alex Shi wrote:
> Currently we just try to find least load cpu. If some cpus idled,
> we just pick the first cpu in cpu mask.
> 
> In fact we can get the interrupted idle cpu or the latest idled cpu,
> then we may get the benefit from both latency and power.
> The selected cpu maybe not the best, since other cpu may be interrupted
> during our selecting. But be captious costs too much.

So the idea here is we want to choose the latest idle cpu if we have
multiple idle cpu for choosing, correct?

And I guess that was in order to avoid choosing tickless cpu while there
are un-tickless idle one, is that right?

What confused me is, what about those cpu who just going to recover from
tickless as you mentioned, which means latest idle doesn't mean the best
choice, or even could be the worst (if just two choice, and the longer
tickless one is just going to recover while the latest is going to
tickless).

So what about just check 'ts->tick_stopped' and record one ticking idle
cpu? the cost could be lower than time comparison, we could reduce the
risk may be...(well, not so risky since the logical only works when
system is relaxing with several cpu idle)

Regards,
Michael Wang

> 
> Signed-off-by: Alex Shi <alex.shi@linaro.org>
> ---
>  kernel/sched/fair.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c7395d9..fb52d26 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4167,6 +4167,26 @@ find_idlest_cpu(struct sched_group *group, struct task_struct *p, int this_cpu)
>  			min_load = load;
>  			idlest = i;
>  		}
> +#ifdef CONFIG_NO_HZ_COMMON
> +		/*
> +		 * Coarsely to get the latest idle cpu for shorter latency and
> +		 * possible power benefit.
> +		 */
> +		if (!min_load) {
> +			struct tick_sched *ts = &per_cpu(tick_cpu_sched, i);
> +
> +			s64 latest_wake = 0;
> +			/* idle cpu doing irq */
> +			if (ts->inidle && !ts->idle_active)
> +				idlest = i;
> +			/* the cpu resched */
> +			else if (!ts->inidle)
> +				idlest = i;
> +			/* find latest idle cpu */
> +			else if (ktime_to_us(ts->idle_entrytime) > latest_wake)
> +				idlest = i;
> +		}
> +#endif
>  	}
> 
>  	return idlest;
> 


  parent reply	other threads:[~2014-01-15  5:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15  4:07 [RFC PATCH] sched: find the latest idle cpu Alex Shi
2014-01-15  4:31 ` Michael wang
2014-01-15  4:48   ` Alex Shi
2014-01-15  4:53     ` Alex Shi
2014-01-15  5:06       ` Alex Shi
2014-01-15  5:33 ` Michael wang [this message]
2014-01-15  6:45   ` Alex Shi
2014-01-15  8:05     ` Michael wang
2014-01-15 14:28       ` Alex Shi
2014-01-15  7:35 ` Peter Zijlstra
2014-01-15 14:37   ` Alex Shi
2014-01-16 11:03     ` Daniel Lezcano
2014-01-16 11:38       ` Peter Zijlstra
2014-01-16 12:16         ` Daniel Lezcano
2014-01-17  2:40           ` Nicolas Pitre

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=52D61DA0.8050206@linux.vnet.ibm.com \
    --to=wangyun@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=fengguang.wu@intel.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --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 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).