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

[Hugh Dickins <hughd@google.com>]

On Fri, 26 Feb 2016, Martin Schwidefsky wrote:
> On Fri, 26 Feb 2016 12:06:50 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, Feb 25, 2016 at 10:50:14PM -0800, Hugh Dickins wrote:
> > 
> > > For example, see the fallback tlb_remove_table_one() in mm/memory.c:
> > > that one uses smp_call_function() sending IPI to all CPUs concerned,
> > > without waiting an RCU grace period at all.
> > 
> > The better comment is with mmu_table_batch.
> > 
> > Its been too long for me to fully remember, nor have I really paid much
> > attention to this code in the past few years, so any memory I might have
> > had might be totally wrong.
> > 
> > But relying on rcu_read_lock_sched() and friends would mean replacing
> > that smp_call_function() with synchronize_sched().
> 
> That makes sense, just tried that together with a big fat printk to see if
> we hit that out-of-memory condition in the page table freeing code.
> The system is swapping like mad but no message so far.
>  
> > A real quick look at the current code seems to suggest that _might_ just
> > work, but note that that will be slower, RT and HPC people will like you
> > for it though.

Thanks for looking, Peter.

Just to make clear, "you" will not be me: apparently simple enough,
but needs a lot more careful testing than I have time to give it.

And here we are just talking about the HAVE_GENERIC_RCU_GUP,
HAVE_RCU_TABLE_FREE architectures (arm, arm64, powerpc, perhaps sparc).

Whether x86 would like to be converted over to the generic RCU GUP,
and give up on its IRQ disabling, is another matter.  Not an argument
I'll get into.  Could be a Kconfig choice I suppose, but that wouldn't
help the distros.

And, for OOM reasons, I do dislike adding any further delay to
freeing pages from exit (or if there's to be an OOM reaper, from zap).

> > 
> > So it depends on how hard we hit that special, totally out of memory,
> > case, and if we care about some performance if we do.
> 
> If the system is out of memory bad enough for the page allocation to fail
> an additional synchronize_sched() call probably won't hurt too much. Most
> of the time we'll be waiting for I/O anyway.

I agree, that case should be too uncommon, and already too slowed, to
worry about any slowdown there - unless it provides an expedited way
out of OOM in some cases - that might be a consideration.

Hugh

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