linux-kernel - Re: [patch 00/20] timer: Refactor the timer wheel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20160615151518.GA11383@linux.vnet.ibm.com>
Date:	Wed, 15 Jun 2016 08:15:18 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Chris Mason <clm@...com>,
	Arjan van de Ven <arjan@...radead.org>, rt@...utronix.de
Subject: Re: [patch 00/20] timer: Refactor the timer wheel

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@...ux.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@...ux.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@...ux.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
>  
>  /*