Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Jul 02, 2015 at 06:47:47PM +0000, Mathieu Desnoyers wrote:
> ----- On Jul 2, 2015, at 2:35 PM, Ingo Molnar mingo@kernel.org wrote:
> 
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > 
> >> > And it's not like it's that hard to stem the flow of algorithmic sloppiness at
> >> > the source, right?
> >> 
> >> OK, first let me make sure that I understand what you are asking for:
> >> 
> >> 1.	Completely eliminate synchronize_rcu_expedited() and
> >> 	synchronize_sched_expedited(), replacing all uses with their
> >> 	unexpedited counterparts.  (Note that synchronize_srcu_expedited()
> >> 	does not wake up CPUs, courtesy of its read-side memory barriers.)
> >> 	The fast-boot guys are probably going to complain, along with
> >> 	the networking guys.
> >> 
> >> 2.	Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
> >> 	but push back hard on any new uses and question any existing uses.
> >> 
> >> 3.	Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in
> >> 	acpi_os_map_cleanup").
> >> 
> >> 4.	Something else?
> > 
> > I'd love to have 1) but 2) would be a realistic second best option? ;-)
> 
> Perhaps triggering a printk warning if use of
> synchronize_{rcu,sched}_expedited() go beyond of certain rate might be
> another option ? If we detect that a caller calls it too often, we could
> emit a printk warning with a stack trace. This should ensure everyone
> is very careful about where they use it.

My first thought is that a storm of expedited grace periods would be
most likely to show up in some error condition, and having them
splat might obscure the splats identifying the real problem.  Or did
you have something else in mind here?

							Thanx, Paul