On Thu, Mar 10, 2016 at 05:34:39PM +0100, Peter Zijlstra wrote: > I'm not seeing that, the only point where this matters at all, is if the > batch alloc fails, otherwise the RCU_TABLE_FREE stuff uses > call_rcu_sched() and what you write above is true already. Not on x86, only if HAVE_RCU_TABLE_FREE is selected, which is not the case for x86: arch/arm/Kconfig: select HAVE_RCU_TABLE_FREE if (SMP && ARM_LPAE) arch/arm64/Kconfig: select HAVE_RCU_TABLE_FREE arch/powerpc/Kconfig: select HAVE_RCU_TABLE_FREE if SMP arch/sparc/Kconfig: select HAVE_RCU_TABLE_FREE if SMP > Normally, as already established by Martin, you should not actually ever > encounter the sync_sched() call. Only under severe memory pressure, when > the batch alloc in tlb_remove_table() fails is this ever an issue. What I mean is that a large mmap/munmap loops may want to be benchmarked to see if they end up stalling in the synchronize_sched case through the memory pressure handler, in turn not restricting the synchronize_sched to a real memory pressure situation but ending up in the memory pressure just because of it. For example the normal load running on ARM isn't as diverse as the one on x86 where RCU_TABLE_FREE has never been exercised at large yet. I doubt anything like that would ever materialize in light load, light munmap load certainly would not be affected. I doubt it'd be ok if munmap end up stalling in synchronize_sched. In fact I'd feel safer if the srcu context can be added to the mm (but that costs memory in the mm unless we're lucky with the slab hw alignment), then I think synchronize_srcu may actually be preferable than a full synchronize_sched that affects the entire system with thousand of CPUs. A per-cpu inc wouldn't be a big deal and it would at least avoid to stall for the whole system if a stall eventually has to happen (unless every cpu is actually running gup_fast but that's ok in such case). About the IRQ safety of synchronize_sched, I was mistaken with sofitrq which can block never mind sorry, of course local_irq_disable or preempt_enable are both valid read barriers as schedule can't run. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>