On Tue, Jun 23, 2015 at 12:55:48PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2015 at 12:09:32PM +0200, Peter Zijlstra wrote: > > We can of course slap a percpu-rwsem in, but I wonder if there's > > anything smarter we can do here. > > Urgh, we cannot use percpu-rwsem here, because that would require > percpu_down_write_trylock(), and I'm not sure we can get around the > sync_sched() for that. > > Now try_stop_cpus(), which requires the down_write_trylock() is used to > implement synchronize_sched_expedited(). > > Using sync_sched() to implement sync_sched_expedited would make me > happy, but it does somewhat defeat the purpose.
Paul, why does this use stop_machine anyway? I seemed to remember you sending resched IPIs around. The rcu_sched_qs() thing would set passed_quiesce, which you can then collect to gauge progress. Shooting IPIs around is bad enough, but running a full blown stop_machine is really blunt and heavy. Also, OMFG @ 74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup"), that's an expedited use to help the nVidiot binary blob. WTF!! -- 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/