Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1420610 > unrolled thread

[patch 00/20] timer: Refactor the timer wheel

Started byThomas Gleixner <tglx@linutronix.de>
First post2016-06-13 10:50 +0200
Last post2016-06-15 22:30 +0200
Articles 10 on this page of 50 — 8 participants

Back to article view | Back to linux.kernel


Contents

  [patch 00/20] timer: Refactor the timer wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 11/20] hlist: Add hlist_is_last_node() helper Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
      Re: [patch 11/20] hlist: Add hlist_is_last_node() helper Paolo Bonzini <pbonzini@redhat.com> - 2016-06-13 12:30 +0200
    [patch 07/20] drivers/tty/mips_ejtag: Initialize timer as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 01/20] timer: Make pinned a timer property Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 17/20] tick/sched: Remove pointless empty function Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 05/20] driver/net/ethernet/tile: Initialize timer as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 15/20] timer: Move __run_timers() function Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 12/20] timer: Give a few structs and members proper names Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 04/20] cpufreq/powernv: Initialize timer as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
      Re: [patch 04/20] cpufreq/powernv: Initialize timer as pinned Arjan van de Ven <arjanvandeven@gmail.com> - 2016-06-13 15:20 +0200
    [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
      Re: [patch 13/20] timer: Switch to a non cascading wheel Peter Zijlstra <peterz@infradead.org> - 2016-06-13 13:50 +0200
        Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 14:40 +0200
          Re: [patch 13/20] timer: Switch to a non cascading wheel Eric Dumazet <edumazet@google.com> - 2016-06-13 14:50 +0200
            Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 16:40 +0200
          Re: [patch 13/20] timer: Switch to a non cascading wheel Ingo Molnar <mingo@kernel.org> - 2016-06-14 12:20 +0200
            Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-14 18:40 +0200
              Re: [patch 13/20] timer: Switch to a non cascading wheel Arjan van de Ven <arjanvandeven@gmail.com> - 2016-06-14 19:20 +0200
                Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-14 20:10 +0200
                  Re: [patch 13/20] timer: Switch to a non cascading wheel Peter Zijlstra <peterz@infradead.org> - 2016-06-14 22:40 +0200
                  Re: [patch 13/20] timer: Switch to a non cascading wheel Peter Zijlstra <peterz@infradead.org> - 2016-06-14 22:50 +0200
                    Re: [patch 13/20] timer: Switch to a non cascading wheel Eric Dumazet <edumazet@google.com> - 2016-06-14 23:20 +0200
                      Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-15 17:00 +0200
                        Re: [patch 13/20] timer: Switch to a non cascading wheel Arjan van de Ven <arjanvandeven@gmail.com> - 2016-06-15 17:00 +0200
                          Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-15 18:50 +0200
                            Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-16 17:50 +0200
                              Re: [patch 13/20] timer: Switch to a non cascading wheel "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-06-16 18:10 +0200
                                Re: [patch 13/20] timer: Switch to a non cascading wheel Peter Zijlstra <peterz@infradead.org> - 2016-06-16 20:20 +0200
                                  Re: [patch 13/20] timer: Switch to a non cascading wheel "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-06-17 02:50 +0200
                                    Re: [patch 13/20] timer: Switch to a non cascading wheel "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-06-17 06:10 +0200
                              Re: [patch 13/20] timer: Switch to a non cascading wheel Arjan van de Ven <arjanvandeven@gmail.com> - 2016-06-16 18:10 +0200
                                Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-16 18:20 +0200
                        Re: [patch 13/20] timer: Switch to a non cascading wheel Eric Dumazet <edumazet@google.com> - 2016-06-15 17:10 +0200
      Re: [patch 13/20] timer: Switch to a non cascading wheel Richard Cochran <richardcochran@gmail.com> - 2016-06-13 16:40 +0200
        Re: [patch 13/20] timer: Switch to a non cascading wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 16:50 +0200
    [patch 14/20] timer: Remove slack leftovers Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
    [patch 18/20] timer: Forward wheel clock whenever possible Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 10:50 +0200
      Re: [patch 18/20] timer: Forward wheel clock whenever possible Richard Cochran <richardcochran@gmail.com> - 2016-06-13 17:20 +0200
        Re: [patch 18/20] timer: Forward wheel clock whenever possible Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 17:30 +0200
    [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 11:00 +0200
      Re: [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned Arjan van de Ven <arjanvandeven@gmail.com> - 2016-06-13 15:20 +0200
    [patch 03/20] x86/mce: Initialize timer as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 11:00 +0200
    [patch 08/20] net/ipv4/inet: Initialize timers as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 11:00 +0200
    [patch 02/20] x86/apic/uv: Initialize timer as pinned Thomas Gleixner <tglx@linutronix.de> - 2016-06-13 11:00 +0200
    Re: [patch 00/20] timer: Refactor the timer wheel Eric Dumazet <edumazet@google.com> - 2016-06-13 16:20 +0200
    Re: [patch 00/20] timer: Refactor the timer wheel "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-06-13 18:20 +0200
      Re: [patch 00/20] timer: Refactor the timer wheel "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-06-15 17:20 +0200
        Re: [patch 00/20] timer: Refactor the timer wheel Thomas Gleixner <tglx@linutronix.de> - 2016-06-15 19:10 +0200
          Re: [patch 00/20] timer: Refactor the timer wheel "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-06-15 22:30 +0200

Page 3 of 3 — ← Prev page 1 2 [3]


#1420627 — [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned

FromThomas Gleixner <tglx@linutronix.de>
Date2016-06-13 11:00 +0200
Subject[patch 06/20] drivers/tty/metag_da: Initialize timer as pinned
Message-ID<rJvT0-3Sn-3@gated-at.bofh.it>
In reply to#1420610
Pinned timers must carry that attribute in the timer itself. No functional
change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/tty/metag_da.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/tty/metag_da.c
===================================================================
--- a/drivers/tty/metag_da.c
+++ b/drivers/tty/metag_da.c
@@ -323,12 +323,12 @@ static void dashtty_timer(unsigned long
 	if (channel >= 0)
 		fetch_data(channel);
 
-	mod_timer_pinned(&poll_timer, jiffies + DA_TTY_POLL);
+	mod_pinned(&poll_timer, jiffies + DA_TTY_POLL);
 }
 
 static void add_poll_timer(struct timer_list *poll_timer)
 {
-	setup_timer(poll_timer, dashtty_timer, 0);
+	setup_pinned_timer(poll_timer, dashtty_timer, 0);
 	poll_timer->expires = jiffies + DA_TTY_POLL;
 
 	/*

[toc] | [prev] | [next] | [standalone]


#1420817 — Re: [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned

FromArjan van de Ven <arjanvandeven@gmail.com>
Date2016-06-13 15:20 +0200
SubjectRe: [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned
Message-ID<rJzWx-6Md-5@gated-at.bofh.it>
In reply to#1420627
I know it's not related to this patch, but it'd be nice to, as you're
changing the api name anyway, make a mod_pinned_relative() so that
more direct users of jiffies can go away...
or even better, mod_pinned_relative_ms() so that these drivers also do
not need to care about HZ.

On Mon, Jun 13, 2016 at 1:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> Pinned timers must carry that attribute in the timer itself. No functional
> change.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  drivers/tty/metag_da.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: b/drivers/tty/metag_da.c
> ===================================================================
> --- a/drivers/tty/metag_da.c
> +++ b/drivers/tty/metag_da.c
> @@ -323,12 +323,12 @@ static void dashtty_timer(unsigned long
>         if (channel >= 0)
>                 fetch_data(channel);
>
> -       mod_timer_pinned(&poll_timer, jiffies + DA_TTY_POLL);
> +       mod_pinned(&poll_timer, jiffies + DA_TTY_POLL);
>  }
>
>  static void add_poll_timer(struct timer_list *poll_timer)
>  {
> -       setup_timer(poll_timer, dashtty_timer, 0);
> +       setup_pinned_timer(poll_timer, dashtty_timer, 0);
>         poll_timer->expires = jiffies + DA_TTY_POLL;
>
>         /*
>
>

[toc] | [prev] | [next] | [standalone]


#1420629 — [patch 03/20] x86/mce: Initialize timer as pinned

FromThomas Gleixner <tglx@linutronix.de>
Date2016-06-13 11:00 +0200
Subject[patch 03/20] x86/mce: Initialize timer as pinned
Message-ID<rJvT0-3Sn-15@gated-at.bofh.it>
In reply to#1420610
Pinned timers must carry that attribute in the timer itself. No functional
change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/cpu/mcheck/mce.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/arch/x86/kernel/cpu/mcheck/mce.c
===================================================================
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1309,7 +1309,7 @@ static void __restart_timer(struct timer
 
 	if (timer_pending(t)) {
 		if (time_before(when, t->expires))
-			mod_timer_pinned(t, when);
+			mod_timer(t, when);
 	} else {
 		t->expires = round_jiffies(when);
 		add_timer_on(t, smp_processor_id());
@@ -1735,7 +1735,7 @@ static void __mcheck_cpu_init_timer(void
 	struct timer_list *t = this_cpu_ptr(&mce_timer);
 	unsigned int cpu = smp_processor_id();
 
-	setup_timer(t, mce_timer_fn, cpu);
+	setup_pinned_timer(t, mce_timer_fn, cpu);
 	mce_start_timer(cpu, t);
 }
 

[toc] | [prev] | [next] | [standalone]


#1420630 — [patch 08/20] net/ipv4/inet: Initialize timers as pinned

FromThomas Gleixner <tglx@linutronix.de>
Date2016-06-13 11:00 +0200
Subject[patch 08/20] net/ipv4/inet: Initialize timers as pinned
Message-ID<rJvT0-3Sn-19@gated-at.bofh.it>
In reply to#1420610
Pinned timers must carry that attribute in the timer itself. No functional
change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 net/ipv4/inet_connection_sock.c |    7 ++++---
 net/ipv4/inet_timewait_sock.c   |    5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

Index: b/net/ipv4/inet_connection_sock.c
===================================================================
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -603,7 +603,7 @@ static void reqsk_timer_handler(unsigned
 		if (req->num_timeout++ == 0)
 			atomic_dec(&queue->young);
 		timeo = min(TCP_TIMEOUT_INIT << req->num_timeout, TCP_RTO_MAX);
-		mod_timer_pinned(&req->rsk_timer, jiffies + timeo);
+		mod_timer(&req->rsk_timer, jiffies + timeo);
 		return;
 	}
 drop:
@@ -617,8 +617,9 @@ static void reqsk_queue_hash_req(struct
 	req->num_timeout = 0;
 	req->sk = NULL;
 
-	setup_timer(&req->rsk_timer, reqsk_timer_handler, (unsigned long)req);
-	mod_timer_pinned(&req->rsk_timer, jiffies + timeout);
+	setup_pinned_timer(&req->rsk_timer, reqsk_timer_handler,
+			    (unsigned long)req);
+	mod_timer(&req->rsk_timer, jiffies + timeout);
 
 	inet_ehash_insert(req_to_sk(req), NULL);
 	/* before letting lookups find us, make sure all req fields
Index: b/net/ipv4/inet_timewait_sock.c
===================================================================
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -188,7 +188,8 @@ struct inet_timewait_sock *inet_twsk_all
 		tw->tw_prot	    = sk->sk_prot_creator;
 		atomic64_set(&tw->tw_cookie, atomic64_read(&sk->sk_cookie));
 		twsk_net_set(tw, sock_net(sk));
-		setup_timer(&tw->tw_timer, tw_timer_handler, (unsigned long)tw);
+		setup_pinned_timer(&tw->tw_timer, tw_timer_handler,
+				   (unsigned long)tw);
 		/*
 		 * Because we use RCU lookups, we should not set tw_refcnt
 		 * to a non null value before everything is setup for this
@@ -248,7 +249,7 @@ void __inet_twsk_schedule(struct inet_ti
 
 	tw->tw_kill = timeo <= 4*HZ;
 	if (!rearm) {
-		BUG_ON(mod_timer_pinned(&tw->tw_timer, jiffies + timeo));
+		BUG_ON(mod_timer(&tw->tw_timer, jiffies + timeo));
 		atomic_inc(&tw->tw_dr->tw_count);
 	} else {
 		mod_timer_pending(&tw->tw_timer, jiffies + timeo);

[toc] | [prev] | [next] | [standalone]


#1420633 — [patch 02/20] x86/apic/uv: Initialize timer as pinned

FromThomas Gleixner <tglx@linutronix.de>
Date2016-06-13 11:00 +0200
Subject[patch 02/20] x86/apic/uv: Initialize timer as pinned
Message-ID<rJvT0-3Sn-17@gated-at.bofh.it>
In reply to#1420610
Pinned timers must carry that attribute in the timer itself. No functional
change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/apic/x2apic_uv_x.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/arch/x86/kernel/apic/x2apic_uv_x.c
===================================================================
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -919,7 +919,7 @@ static void uv_heartbeat(unsigned long i
 	uv_set_scir_bits(bits);
 
 	/* enable next timer period */
-	mod_timer_pinned(timer, jiffies + SCIR_CPU_HB_INTERVAL);
+	mod_timer(timer, jiffies + SCIR_CPU_HB_INTERVAL);
 }
 
 static void uv_heartbeat_enable(int cpu)
@@ -928,7 +928,7 @@ static void uv_heartbeat_enable(int cpu)
 		struct timer_list *timer = &uv_cpu_scir_info(cpu)->timer;
 
 		uv_set_cpu_scir_bits(cpu, SCIR_CPU_HEARTBEAT|SCIR_CPU_ACTIVITY);
-		setup_timer(timer, uv_heartbeat, cpu);
+		setup_pinned_timer(timer, uv_heartbeat, cpu);
 		timer->expires = jiffies + SCIR_CPU_HB_INTERVAL;
 		add_timer_on(timer, cpu);
 		uv_cpu_scir_info(cpu)->enabled = 1;

[toc] | [prev] | [next] | [standalone]


#1420903

FromEric Dumazet <edumazet@google.com>
Date2016-06-13 16:20 +0200
Message-ID<rJASC-7p1-39@gated-at.bofh.it>
In reply to#1420610
On Mon, Jun 13, 2016 at 1:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> The current timer wheel has some drawbacks:

...

> This series has also preparatory patches for changing the NOHZ timer handling
> from the current push to a pull model. Currently we decide at timer enqueue
> time on which cpu we queue the timer. This is exceptionally silly because
> there is no way to predict at enqueue time which cpu will be idle when the
> timer expires. Given the fact that most timers are canceled or rearmed before
> expiry this is even more silly. We trade a expensive decision and cross cpu
> access for a very doubtful benefit.
>

Also many TCP timers are armed from softirq handler interrupting idle task,
so scheduler believes current cpu is idle .

This patch series is really nice Thomas.

[toc] | [prev] | [next] | [standalone]


#1421038

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2016-06-13 18:20 +0200
Message-ID<rJCKK-eX-17@gated-at.bofh.it>
In reply to#1420610
On Mon, Jun 13, 2016 at 08:40:50AM -0000, Thomas Gleixner wrote:
> The current timer wheel has some drawbacks:
> 
> 1) Cascading
> 
>    Cascading can be an unbound operation and is completely pointless in most
>    cases because the vast majority of the timer wheel timers are canceled or
>    rearmed before expiration.
> 
> 2) No fast lookup of the next expiring timer
> 
>    In NOHZ scenarios the first timer soft interrupt after a long NOHZ period
>    must fast forward the base time to current jiffies. As we have no way to
>    find the next expiring timer fast, the code loops and increments the base
>    time by one and checks for expired timers in each step. I've observed loops
>    lasting 1 ms!
> 
> There are some other issues caused by the above, but they are minor compare to
> those.

For SMP configurations, this passes light rcutorture testing.  For UP
builds, it complains about undefined symbols.  Builds succeed with
the following kneejerk patch.  Am retesting rcutorture.

							Thanx, Paul

------------------------------------------------------------------------

commit 87dbd35cf4034f2b664b6e9d60decd2bdbfc416f
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon Jun 13 09:11:41 2016 -0700

    Fix undefined get_nohz_timer_target() in non-SMP builds
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6e42ada26345..322e52415a29 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -348,6 +348,10 @@ extern int get_nohz_timer_target(void);
 #else
 static inline void nohz_balance_enter_idle(int cpu) { }
 static inline void set_cpu_sd_state_idle(void) { }
+static inline int get_nohz_timer_target(void)
+{
+	return raw_smp_processor_id();
+}
 #endif
 
 /*

[toc] | [prev] | [next] | [standalone]


#1423128

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2016-06-15 17:20 +0200
Message-ID<rKkLL-4en-5@gated-at.bofh.it>
In reply to#1421038
On Mon, Jun 13, 2016 at 09:15:14AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 13, 2016 at 08:40:50AM -0000, Thomas Gleixner wrote:
> > The current timer wheel has some drawbacks:
> > 
> > 1) Cascading
> > 
> >    Cascading can be an unbound operation and is completely pointless in most
> >    cases because the vast majority of the timer wheel timers are canceled or
> >    rearmed before expiration.
> > 
> > 2) No fast lookup of the next expiring timer
> > 
> >    In NOHZ scenarios the first timer soft interrupt after a long NOHZ period
> >    must fast forward the base time to current jiffies. As we have no way to
> >    find the next expiring timer fast, the code loops and increments the base
> >    time by one and checks for expired timers in each step. I've observed loops
> >    lasting 1 ms!
> > 
> > There are some other issues caused by the above, but they are minor compare to
> > those.
> 
> For SMP configurations, this passes light rcutorture testing.  For UP
> builds, it complains about undefined symbols.  Builds succeed with
> the following kneejerk patch.  Am retesting rcutorture.

And with the patch below, testing goes as well with your patch stack as
it does without it.  So, with that patch (or equivalent):

Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

There were some complaints about increasing the size of the tiny
configuration, FYI.

So, just out of curiosity, does anyone still run -rt on single-CPU systems?

							Thanx, Paul

> ------------------------------------------------------------------------
> 
> commit 87dbd35cf4034f2b664b6e9d60decd2bdbfc416f
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Mon Jun 13 09:11:41 2016 -0700
> 
>     Fix undefined get_nohz_timer_target() in non-SMP builds
>     
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 6e42ada26345..322e52415a29 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -348,6 +348,10 @@ extern int get_nohz_timer_target(void);
>  #else
>  static inline void nohz_balance_enter_idle(int cpu) { }
>  static inline void set_cpu_sd_state_idle(void) { }
> +static inline int get_nohz_timer_target(void)
> +{
> +	return raw_smp_processor_id();
> +}
>  #endif
>  
>  /*

[toc] | [prev] | [next] | [standalone]


#1423245

FromThomas Gleixner <tglx@linutronix.de>
Date2016-06-15 19:10 +0200
Message-ID<rKmud-5m4-9@gated-at.bofh.it>
In reply to#1423128
On Wed, 15 Jun 2016, Paul E. McKenney wrote:
> On Mon, Jun 13, 2016 at 09:15:14AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 13, 2016 at 08:40:50AM -0000, Thomas Gleixner wrote:
> > > The current timer wheel has some drawbacks:
> > > 
> > > 1) Cascading
> > > 
> > >    Cascading can be an unbound operation and is completely pointless in most
> > >    cases because the vast majority of the timer wheel timers are canceled or
> > >    rearmed before expiration.
> > > 
> > > 2) No fast lookup of the next expiring timer
> > > 
> > >    In NOHZ scenarios the first timer soft interrupt after a long NOHZ period
> > >    must fast forward the base time to current jiffies. As we have no way to
> > >    find the next expiring timer fast, the code loops and increments the base
> > >    time by one and checks for expired timers in each step. I've observed loops
> > >    lasting 1 ms!
> > > 
> > > There are some other issues caused by the above, but they are minor compare to
> > > those.
> > 
> > For SMP configurations, this passes light rcutorture testing.  For UP
> > builds, it complains about undefined symbols.  Builds succeed with
> > the following kneejerk patch.  Am retesting rcutorture.
> 
> And with the patch below, testing goes as well with your patch stack as
> it does without it.  So, with that patch (or equivalent):
> 
> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> There were some complaints about increasing the size of the tiny
> configuration, FYI.

I know. The extra storage space for the deferrable stuff makes it larger along
with the extra code for avoiding all the crap which the current wheel suffers
from :) Do the tiny people need NOHZ?

> So, just out of curiosity, does anyone still run -rt on single-CPU systems?

Of course :)

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]


#1423421

From"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date2016-06-15 22:30 +0200
Message-ID<rKpBM-7cb-35@gated-at.bofh.it>
In reply to#1423245
On Wed, Jun 15, 2016 at 07:02:38PM +0200, Thomas Gleixner wrote:
> On Wed, 15 Jun 2016, Paul E. McKenney wrote:
> > On Mon, Jun 13, 2016 at 09:15:14AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jun 13, 2016 at 08:40:50AM -0000, Thomas Gleixner wrote:
> > > > The current timer wheel has some drawbacks:
> > > > 
> > > > 1) Cascading
> > > > 
> > > >    Cascading can be an unbound operation and is completely pointless in most
> > > >    cases because the vast majority of the timer wheel timers are canceled or
> > > >    rearmed before expiration.
> > > > 
> > > > 2) No fast lookup of the next expiring timer
> > > > 
> > > >    In NOHZ scenarios the first timer soft interrupt after a long NOHZ period
> > > >    must fast forward the base time to current jiffies. As we have no way to
> > > >    find the next expiring timer fast, the code loops and increments the base
> > > >    time by one and checks for expired timers in each step. I've observed loops
> > > >    lasting 1 ms!
> > > > 
> > > > There are some other issues caused by the above, but they are minor compare to
> > > > those.
> > > 
> > > For SMP configurations, this passes light rcutorture testing.  For UP
> > > builds, it complains about undefined symbols.  Builds succeed with
> > > the following kneejerk patch.  Am retesting rcutorture.
> > 
> > And with the patch below, testing goes as well with your patch stack as
> > it does without it.  So, with that patch (or equivalent):
> > 
> > Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > There were some complaints about increasing the size of the tiny
> > configuration, FYI.
> 
> I know. The extra storage space for the deferrable stuff makes it larger along
> with the extra code for avoiding all the crap which the current wheel suffers
> from :) Do the tiny people need NOHZ?

If it makes the code bigger, I would hope that they don't need it.

> > So, just out of curiosity, does anyone still run -rt on single-CPU systems?
> 
> Of course :)

Hey, had to ask!  ;-)

								Thanx, Paul

[toc] | [prev] | [standalone]


Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel


csiph-web