Re: [PATCH] thp, mm: remove comments on serializion of THP split vs. gup_fast

[Andrea Arcangeli <aarcange@redhat.com>]

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@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>