On Fri, 26 Feb 2016 12:06:50 +0100 Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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. > > 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. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- 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>