linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Arjan van de Ven <arjan@linux.jf.intel.com>,
	Venkatesh Pallipadi <venki@google.com>,
	ego@in.ibm.com, LKML <linux-kernel@vger.kernel.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Nigel Cunningham <ncunningham@crca.org.au>
Subject: Re: [patch 7/7] timers: use nearest busy cpu for migrating timers from an idle cpu
Date: Wed, 2 Jun 2010 05:07:32 +0530	[thread overview]
Message-ID: <20100601233732.GB7764@dirshya.in.ibm.com> (raw)
In-Reply-To: <20100517184028.114595207@sbs-t61.sc.intel.com>

* Suresh Siddha <suresh.b.siddha@intel.com> [2010-05-17 11:27:33]:

> Currently we are migrating the unpinned timers from an idle to the cpu
> doing idle load balancing (when all the cpus in the system are idle,
> there is no idle load balacncing cpu and timers get added to the same idle cpu
> where the request was made. So the current optimization works only on semi idle
> system).
> 
> And In semi idle system, we no longer have periodic ticks on the idle cpu
> doing the idle load balancing on behalf of all the cpu's. Using that cpu
> will add more delays to the timers than intended (as that cpu's timer base
> may not be uptodate wrt jiffies etc). This was causing mysterious slowdowns
> during boot etc.

Hi Suresh,

Can please give more info on why this caused delay in bootup or timer
event.  The jiffies should be updated even with the current push model
right.  We will still have some pinned timer on the idle cpu and the
time base will have to be updated when the timer event happens.

> 
> For now, in the semi idle case, use the nearest busy cpu for migrating timers from an
> idle cpu.  This is good for power-savings anyway.

Yes.  This is good solution.  But on a large system the only running
cpu may accumulate too may timers that could affect the performance of
the task running.  We will need to test this out.

> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> ---
>  include/linux/sched.h |    2 +-
>  kernel/hrtimer.c      |    8 ++------
>  kernel/sched.c        |   13 +++++++++++++
>  kernel/timer.c        |    8 ++------
>  4 files changed, 18 insertions(+), 13 deletions(-)
> 
> Index: tip/kernel/hrtimer.c
> ===================================================================
> --- tip.orig/kernel/hrtimer.c
> +++ tip/kernel/hrtimer.c
> @@ -144,12 +144,8 @@ struct hrtimer_clock_base *lock_hrtimer_
>  static int hrtimer_get_target(int this_cpu, int pinned)
>  {
>  #ifdef CONFIG_NO_HZ
> -	if (!pinned && get_sysctl_timer_migration() && idle_cpu(this_cpu)) {
> -		int preferred_cpu = get_nohz_load_balancer();
> -
> -		if (preferred_cpu < nr_cpu_ids)
> -			return preferred_cpu;
> -	}
> +	if (!pinned && get_sysctl_timer_migration() && idle_cpu(this_cpu))
> +		return get_nohz_timer_target();
>  #endif
>  	return this_cpu;
>  }
> Index: tip/kernel/sched.c
> ===================================================================
> --- tip.orig/kernel/sched.c
> +++ tip/kernel/sched.c
> @@ -1201,6 +1201,19 @@ static void resched_cpu(int cpu)
>  }
> 
>  #ifdef CONFIG_NO_HZ
> +int get_nohz_timer_target(void)
> +{
> +	int cpu = smp_processor_id();
> +	int i;
> +	struct sched_domain *sd;
> +
> +	for_each_domain(cpu, sd) {
> +		for_each_cpu(i, sched_domain_span(sd))
> +			if (!idle_cpu(i))
> +				return i;
> +	}
> +	return cpu;
> +}

We will need a better way of finding the right CPU since this code
will take longer time on a larger system with one or two busy cpus.

We should perhaps pick the cpu from the compliment of the current
nohz.grp_idle_mask or something derived from these masks instead of
searching in the sched domain.  Only advantage I see is that we will
get the busy CPU nearest as in same node which is better.

--Vaidy

[snip]

  reply	other threads:[~2010-06-01 23:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-17 18:27 [patch 0/7] sched: change nohz idle load balancing logic to push model Suresh Siddha
2010-05-17 18:27 ` [patch 1/7] softirq: Add a no local fallback option to send_remote_softirq Suresh Siddha
2010-05-17 18:27 ` [patch 2/7] softirq: add init_remote_softirq_csd() Suresh Siddha
2010-05-17 18:27 ` [patch 3/7] softirq: avoid softirq_work_list for SCHED_SOFTIRQ when sent remotely Suresh Siddha
2010-05-20  8:12   ` Peter Zijlstra
2010-05-20  8:14     ` David Miller
2010-05-20  8:23       ` Jens Axboe
2010-05-20  8:29         ` Peter Zijlstra
2010-05-20  9:18         ` David Miller
2010-05-17 18:27 ` [patch 4/7] sched: Change nohz ilb logic from pull to push model Suresh Siddha
2010-06-01 23:47   ` Vaidyanathan Srinivasan
2010-06-02 22:27     ` Suresh Siddha
2010-05-17 18:27 ` [patch 5/7] sched: Change select_nohz_load_balancer to return void Suresh Siddha
2010-05-17 18:27 ` [patch 6/7] sched: change nohz.load_balancer to be nr_cpu_ids based Suresh Siddha
2010-05-20  9:49   ` Peter Zijlstra
2010-05-17 18:27 ` [patch 7/7] timers: use nearest busy cpu for migrating timers from an idle cpu Suresh Siddha
2010-06-01 23:37   ` Vaidyanathan Srinivasan [this message]
2010-06-02 22:02     ` Suresh Siddha
2010-05-17 22:39 ` [patch 0/7] sched: change nohz idle load balancing logic to push model Nigel Cunningham
2010-05-19  9:19   ` Dominik Brodowski
2010-05-20 10:50 ` Peter Zijlstra
2010-05-22  0:09   ` Suresh Siddha
2010-05-31  9:17     ` Peter Zijlstra
2010-06-09 10:13     ` [tip:sched/core] sched: Change " tip-bot for Venkatesh Pallipadi
2010-05-20 11:07 ` [patch 0/7] sched: change " Nigel Cunningham
2010-05-20 11:17   ` Dominik Brodowski
2010-05-20 11:35     ` Nigel Cunningham
2010-05-20 12:13       ` Dominik Brodowski

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=20100601233732.GB7764@dirshya.in.ibm.com \
    --to=svaidy@linux.vnet.ibm.com \
    --cc=arjan@linux.jf.intel.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mingo@elte.hu \
    --cc=ncunningham@crca.org.au \
    --cc=peterz@infradead.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venki@google.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).