On Thu, Mar 10, 2016 at 05:34:39PM +0100, Peter Zijlstra wrote: > > > Then there's another issue with synchronize_sched(), > > __get_user_pages_fast has to safe to run from irq (note the > > local_irq_save instead of local_irq_disable) and KVM leverages it. > > This is unchanged. synchronize_sched() serialized against anything that > disables preemption, having IRQs disabled is very much included in that. > > So there should be no problem running this from IRQ context. Think of it this way: synchronize_sched() waits for every cpu to have called schedule() at least once. If you're inside an IRQ handler, you cannot call schedule(), therefore the RCU (sched) QS cannot progress and any dereferences you make must stay valid. > > Overall my main concern in switching x86 to RCU gup-fast is the > > performance of synchronize_sched in large munmap pagetable teardown. > > 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. > > And at the point where such allocations fail, performance typically > isn't a concern anymore. Note, I'm not advocating switching x86 over (although it might be an interested experiment), I just wanted to clarify some points I perceived you were not entirely clear on. -- 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>