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:

quoted

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>