On Thu, Mar 10, 2016 at 06:22:49PM +0100, Andrea Arcangeli wrote: > On Thu, Mar 10, 2016 at 06:04:06PM +0100, Andrea Arcangeli wrote: > > 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). > > Thinking more about this, it'd be ok if the pgtable freeing srcu > context was global, no need of mess with the mm. A __percpu inside mm > wouldn't fly anyway. With srcu we'd wait only for those CPUs that are > effectively inside gup_fast, most of the time none or a few. You've not looked at srcu, right? That's not going to make it faster, not without some serious surgery. -- 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>