* [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls [not found] <20200623002128.GA25456@paulmck-ThinkPad-P72> @ 2020-06-23 0:21 ` paulmck 2020-06-23 0:47 ` Shakeel Butt 2020-06-23 19:34 ` Joel Fernandes 0 siblings, 2 replies; 6+ messages in thread From: paulmck @ 2020-06-23 0:21 UTC (permalink / raw) To: rcu Cc: linux-kernel, kernel-team, mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, joel, Paul E. McKenney, linux-mm From: "Paul E. McKenney" <paulmck@kernel.org> A large process running on a heavily loaded system can encounter the following RCU CPU stall warning: rcu: INFO: rcu_sched self-detected stall on CPU rcu: \x093-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190 \x09(t=21013 jiffies g=1005461 q=132576) NMI backtrace for cpu 3 CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1 Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016 Call Trace: <IRQ> dump_stack+0x46/0x60 nmi_cpu_backtrace.cold.3+0x13/0x50 ? lapic_can_unplug_cpu.cold.27+0x34/0x34 nmi_trigger_cpumask_backtrace+0xba/0xca rcu_dump_cpu_stacks+0x99/0xc7 rcu_sched_clock_irq.cold.87+0x1aa/0x397 ? tick_sched_do_timer+0x60/0x60 update_process_times+0x28/0x60 tick_sched_timer+0x37/0x70 __hrtimer_run_queues+0xfe/0x270 hrtimer_interrupt+0xf4/0x210 smp_apic_timer_interrupt+0x5e/0x120 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0010:kmem_cache_free+0x223/0x300 Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65 RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030 RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18 RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00 ? remove_vma+0x4f/0x60 remove_vma+0x4f/0x60 exit_mmap+0xd6/0x160 mmput+0x4a/0x110 do_exit+0x278/0xae0 ? syscall_trace_enter+0x1d3/0x2b0 ? handle_mm_fault+0xaa/0x1c0 do_group_exit+0x3a/0xa0 __x64_sys_exit_group+0x14/0x20 do_syscall_64+0x42/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run for a very long time given a large process. This commit therefore adds a cond_resched() to this loop, providing RCU any needed quiescent states. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <linux-mm@kvack.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> --- mm/mmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/mmap.c b/mm/mmap.c index 59a4682..972f839 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -3159,6 +3159,7 @@ void exit_mmap(struct mm_struct *mm) if (vma->vm_flags & VM_ACCOUNT) nr_accounted += vma_pages(vma); vma = remove_vma(vma); + cond_resched(); } vm_unacct_memory(nr_accounted); } -- 2.9.5 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls 2020-06-23 0:21 ` [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls paulmck @ 2020-06-23 0:47 ` Shakeel Butt 2020-06-23 0:57 ` Paul E. McKenney 2020-06-23 19:34 ` Joel Fernandes 1 sibling, 1 reply; 6+ messages in thread From: Shakeel Butt @ 2020-06-23 0:47 UTC (permalink / raw) To: paulmck, David Rientjes Cc: rcu, LKML, Kernel Team, Ingo Molnar, jiangshanlai, dipankar, Andrew Morton, Mathieu Desnoyers, josh, Thomas Gleixner, Peter Zijlstra (Intel), Steven Rostedt, David Howells, Eric Dumazet, fweisbec, oleg, Joel Fernandes, Linux MM On Mon, Jun 22, 2020 at 5:22 PM <paulmck@kernel.org> wrote: > > From: "Paul E. McKenney" <paulmck@kernel.org> > > A large process running on a heavily loaded system can encounter the > following RCU CPU stall warning: > > rcu: INFO: rcu_sched self-detected stall on CPU > rcu: \x093-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190 > \x09(t=21013 jiffies g=1005461 q=132576) > NMI backtrace for cpu 3 > CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1 > Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016 > Call Trace: > <IRQ> > dump_stack+0x46/0x60 > nmi_cpu_backtrace.cold.3+0x13/0x50 > ? lapic_can_unplug_cpu.cold.27+0x34/0x34 > nmi_trigger_cpumask_backtrace+0xba/0xca > rcu_dump_cpu_stacks+0x99/0xc7 > rcu_sched_clock_irq.cold.87+0x1aa/0x397 > ? tick_sched_do_timer+0x60/0x60 > update_process_times+0x28/0x60 > tick_sched_timer+0x37/0x70 > __hrtimer_run_queues+0xfe/0x270 > hrtimer_interrupt+0xf4/0x210 > smp_apic_timer_interrupt+0x5e/0x120 > apic_timer_interrupt+0xf/0x20 > </IRQ> > RIP: 0010:kmem_cache_free+0x223/0x300 > Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65 > RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 > RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030 > RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18 > RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff > R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f > R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00 > ? remove_vma+0x4f/0x60 > remove_vma+0x4f/0x60 > exit_mmap+0xd6/0x160 > mmput+0x4a/0x110 > do_exit+0x278/0xae0 > ? syscall_trace_enter+0x1d3/0x2b0 > ? handle_mm_fault+0xaa/0x1c0 > do_group_exit+0x3a/0xa0 > __x64_sys_exit_group+0x14/0x20 > do_syscall_64+0x42/0x100 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run > for a very long time given a large process. This commit therefore adds > a cond_resched() to this loop, providing RCU any needed quiescent states. > > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: <linux-mm@kvack.org> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> We have exactly the same change in our internal kernel since 2018. We mostly observed the need_resched warnings on the processes mapping the hugetlbfs. Reviewed-by: Shakeel Butt <shakeelb@google.com> > --- > mm/mmap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 59a4682..972f839 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3159,6 +3159,7 @@ void exit_mmap(struct mm_struct *mm) > if (vma->vm_flags & VM_ACCOUNT) > nr_accounted += vma_pages(vma); > vma = remove_vma(vma); > + cond_resched(); > } > vm_unacct_memory(nr_accounted); > } > -- > 2.9.5 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls 2020-06-23 0:47 ` Shakeel Butt @ 2020-06-23 0:57 ` Paul E. McKenney 0 siblings, 0 replies; 6+ messages in thread From: Paul E. McKenney @ 2020-06-23 0:57 UTC (permalink / raw) To: Shakeel Butt Cc: David Rientjes, rcu, LKML, Kernel Team, Ingo Molnar, jiangshanlai, dipankar, Andrew Morton, Mathieu Desnoyers, josh, Thomas Gleixner, Peter Zijlstra (Intel), Steven Rostedt, David Howells, Eric Dumazet, fweisbec, oleg, Joel Fernandes, Linux MM On Mon, Jun 22, 2020 at 05:47:19PM -0700, Shakeel Butt wrote: > On Mon, Jun 22, 2020 at 5:22 PM <paulmck@kernel.org> wrote: > > > > From: "Paul E. McKenney" <paulmck@kernel.org> > > > > A large process running on a heavily loaded system can encounter the > > following RCU CPU stall warning: > > > > rcu: INFO: rcu_sched self-detected stall on CPU > > rcu: \x093-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190 > > \x09(t=21013 jiffies g=1005461 q=132576) > > NMI backtrace for cpu 3 > > CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1 > > Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016 > > Call Trace: > > <IRQ> > > dump_stack+0x46/0x60 > > nmi_cpu_backtrace.cold.3+0x13/0x50 > > ? lapic_can_unplug_cpu.cold.27+0x34/0x34 > > nmi_trigger_cpumask_backtrace+0xba/0xca > > rcu_dump_cpu_stacks+0x99/0xc7 > > rcu_sched_clock_irq.cold.87+0x1aa/0x397 > > ? tick_sched_do_timer+0x60/0x60 > > update_process_times+0x28/0x60 > > tick_sched_timer+0x37/0x70 > > __hrtimer_run_queues+0xfe/0x270 > > hrtimer_interrupt+0xf4/0x210 > > smp_apic_timer_interrupt+0x5e/0x120 > > apic_timer_interrupt+0xf/0x20 > > </IRQ> > > RIP: 0010:kmem_cache_free+0x223/0x300 > > Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65 > > RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 > > RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030 > > RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18 > > RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff > > R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f > > R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00 > > ? remove_vma+0x4f/0x60 > > remove_vma+0x4f/0x60 > > exit_mmap+0xd6/0x160 > > mmput+0x4a/0x110 > > do_exit+0x278/0xae0 > > ? syscall_trace_enter+0x1d3/0x2b0 > > ? handle_mm_fault+0xaa/0x1c0 > > do_group_exit+0x3a/0xa0 > > __x64_sys_exit_group+0x14/0x20 > > do_syscall_64+0x42/0x100 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run > > for a very long time given a large process. This commit therefore adds > > a cond_resched() to this loop, providing RCU any needed quiescent states. > > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: <linux-mm@kvack.org> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > We have exactly the same change in our internal kernel since 2018. We > mostly observed the need_resched warnings on the processes mapping the > hugetlbfs. > > Reviewed-by: Shakeel Butt <shakeelb@google.com> Thank you very much, I will apply your Reviewed-by on the next rebase. Any other patches we should know about? ;-) Thanx, Paul > > --- > > mm/mmap.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 59a4682..972f839 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -3159,6 +3159,7 @@ void exit_mmap(struct mm_struct *mm) > > if (vma->vm_flags & VM_ACCOUNT) > > nr_accounted += vma_pages(vma); > > vma = remove_vma(vma); > > + cond_resched(); > > } > > vm_unacct_memory(nr_accounted); > > } > > -- > > 2.9.5 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls 2020-06-23 0:21 ` [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls paulmck 2020-06-23 0:47 ` Shakeel Butt @ 2020-06-23 19:34 ` Joel Fernandes 2020-06-23 20:55 ` Paul E. McKenney 1 sibling, 1 reply; 6+ messages in thread From: Joel Fernandes @ 2020-06-23 19:34 UTC (permalink / raw) To: paulmck Cc: rcu, linux-kernel, kernel-team, mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, linux-mm On Mon, Jun 22, 2020 at 05:21:23PM -0700, paulmck@kernel.org wrote: > From: "Paul E. McKenney" <paulmck@kernel.org> > > A large process running on a heavily loaded system can encounter the > following RCU CPU stall warning: > > rcu: INFO: rcu_sched self-detected stall on CPU > rcu: \x093-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190 > \x09(t=21013 jiffies g=1005461 q=132576) > NMI backtrace for cpu 3 > CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1 > Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016 > Call Trace: > <IRQ> > dump_stack+0x46/0x60 > nmi_cpu_backtrace.cold.3+0x13/0x50 > ? lapic_can_unplug_cpu.cold.27+0x34/0x34 > nmi_trigger_cpumask_backtrace+0xba/0xca > rcu_dump_cpu_stacks+0x99/0xc7 > rcu_sched_clock_irq.cold.87+0x1aa/0x397 > ? tick_sched_do_timer+0x60/0x60 > update_process_times+0x28/0x60 > tick_sched_timer+0x37/0x70 > __hrtimer_run_queues+0xfe/0x270 > hrtimer_interrupt+0xf4/0x210 > smp_apic_timer_interrupt+0x5e/0x120 > apic_timer_interrupt+0xf/0x20 > </IRQ> > RIP: 0010:kmem_cache_free+0x223/0x300 > Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65 > RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 > RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030 > RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18 > RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff > R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f > R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00 > ? remove_vma+0x4f/0x60 > remove_vma+0x4f/0x60 > exit_mmap+0xd6/0x160 > mmput+0x4a/0x110 > do_exit+0x278/0xae0 > ? syscall_trace_enter+0x1d3/0x2b0 > ? handle_mm_fault+0xaa/0x1c0 > do_group_exit+0x3a/0xa0 > __x64_sys_exit_group+0x14/0x20 > do_syscall_64+0x42/0x100 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run > for a very long time given a large process. This commit therefore adds > a cond_resched() to this loop, providing RCU any needed quiescent states. > > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: <linux-mm@kvack.org> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > --- > mm/mmap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 59a4682..972f839 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3159,6 +3159,7 @@ void exit_mmap(struct mm_struct *mm) > if (vma->vm_flags & VM_ACCOUNT) > nr_accounted += vma_pages(vma); > vma = remove_vma(vma); > + cond_resched(); Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Just for my understanding, cond_resched_tasks_rcu_qs() may not help here because preemption is not disabled right? Still I see no harm in using it here either as it may give a slight speed up for tasks-RCU. thanks, - Joel > } > vm_unacct_memory(nr_accounted); > } > -- > 2.9.5 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls 2020-06-23 19:34 ` Joel Fernandes @ 2020-06-23 20:55 ` Paul E. McKenney 2020-06-23 21:01 ` Joel Fernandes 0 siblings, 1 reply; 6+ messages in thread From: Paul E. McKenney @ 2020-06-23 20:55 UTC (permalink / raw) To: Joel Fernandes Cc: rcu, linux-kernel, kernel-team, mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, linux-mm On Tue, Jun 23, 2020 at 03:34:31PM -0400, Joel Fernandes wrote: > On Mon, Jun 22, 2020 at 05:21:23PM -0700, paulmck@kernel.org wrote: > > From: "Paul E. McKenney" <paulmck@kernel.org> > > > > A large process running on a heavily loaded system can encounter the > > following RCU CPU stall warning: > > > > rcu: INFO: rcu_sched self-detected stall on CPU > > rcu: \x093-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190 > > \x09(t=21013 jiffies g=1005461 q=132576) > > NMI backtrace for cpu 3 > > CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1 > > Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016 > > Call Trace: > > <IRQ> > > dump_stack+0x46/0x60 > > nmi_cpu_backtrace.cold.3+0x13/0x50 > > ? lapic_can_unplug_cpu.cold.27+0x34/0x34 > > nmi_trigger_cpumask_backtrace+0xba/0xca > > rcu_dump_cpu_stacks+0x99/0xc7 > > rcu_sched_clock_irq.cold.87+0x1aa/0x397 > > ? tick_sched_do_timer+0x60/0x60 > > update_process_times+0x28/0x60 > > tick_sched_timer+0x37/0x70 > > __hrtimer_run_queues+0xfe/0x270 > > hrtimer_interrupt+0xf4/0x210 > > smp_apic_timer_interrupt+0x5e/0x120 > > apic_timer_interrupt+0xf/0x20 > > </IRQ> > > RIP: 0010:kmem_cache_free+0x223/0x300 > > Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65 > > RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 > > RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030 > > RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18 > > RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff > > R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f > > R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00 > > ? remove_vma+0x4f/0x60 > > remove_vma+0x4f/0x60 > > exit_mmap+0xd6/0x160 > > mmput+0x4a/0x110 > > do_exit+0x278/0xae0 > > ? syscall_trace_enter+0x1d3/0x2b0 > > ? handle_mm_fault+0xaa/0x1c0 > > do_group_exit+0x3a/0xa0 > > __x64_sys_exit_group+0x14/0x20 > > do_syscall_64+0x42/0x100 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run > > for a very long time given a large process. This commit therefore adds > > a cond_resched() to this loop, providing RCU any needed quiescent states. > > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: <linux-mm@kvack.org> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > --- > > mm/mmap.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 59a4682..972f839 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -3159,6 +3159,7 @@ void exit_mmap(struct mm_struct *mm) > > if (vma->vm_flags & VM_ACCOUNT) > > nr_accounted += vma_pages(vma); > > vma = remove_vma(vma); > > + cond_resched(); > > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Thank you! I will apply this on my next rebase. > Just for my understanding, cond_resched_tasks_rcu_qs() may not help here > because preemption is not disabled right? Still I see no harm in using it > here either as it may give a slight speed up for tasks-RCU. The RCU-tasks stall-warning interval is ten minutes, and I have not yet seen evidence that we are getting close to that. If we do, then yes, a cond_resched_tasks_rcu_qs() might be in this code's future. But it does add overhead, so we need to see the evidence first. Thanx, Paul > thanks, > > - Joel > > > } > > vm_unacct_memory(nr_accounted); > > } > > -- > > 2.9.5 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls 2020-06-23 20:55 ` Paul E. McKenney @ 2020-06-23 21:01 ` Joel Fernandes 0 siblings, 0 replies; 6+ messages in thread From: Joel Fernandes @ 2020-06-23 21:01 UTC (permalink / raw) To: Paul E. McKenney Cc: rcu, linux-kernel, kernel-team, mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, linux-mm On Tue, Jun 23, 2020 at 01:55:08PM -0700, Paul E. McKenney wrote: [..] > > Just for my understanding, cond_resched_tasks_rcu_qs() may not help here > > because preemption is not disabled right? Still I see no harm in using it > > here either as it may give a slight speed up for tasks-RCU. > > The RCU-tasks stall-warning interval is ten minutes, and I have not yet > seen evidence that we are getting close to that. If we do, then yes, > a cond_resched_tasks_rcu_qs() might be in this code's future. But it > does add overhead, so we need to see the evidence first. Yes, true about that overhead. Ok, this is fine with me too, thanks :) - Joel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-23 21:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200623002128.GA25456@paulmck-ThinkPad-P72>
2020-06-23 0:21 ` [PATCH tip/core/rcu 02/26] mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls paulmck
2020-06-23 0:47 ` Shakeel Butt
2020-06-23 0:57 ` Paul E. McKenney
2020-06-23 19:34 ` Joel Fernandes
2020-06-23 20:55 ` Paul E. McKenney
2020-06-23 21:01 ` Joel Fernandes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).