* Paul E. McKenney <paul...@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? ;-) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/