Re: [PATCH v6 3/5] lazy tlb: shoot lazies, non-refcounting lazy tlb mm reference handling scheme
From: "Nicholas Piggin" <npiggin@gmail.com>
Date: 2023-01-19 00:53:18
Also in:
linux-arch, linux-mm
From: "Nicholas Piggin" <npiggin@gmail.com>
Date: 2023-01-19 00:53:18
Also in:
linux-arch, linux-mm
On Thu Jan 19, 2023 at 8:22 AM AEST, Nadav Amit wrote:
quoted
On Jan 18, 2023, at 12:00 AM, Nicholas Piggin [off-list ref] wrote: +static void do_shoot_lazy_tlb(void *arg) +{ + struct mm_struct *mm = arg; + + if (current->active_mm == mm) { + WARN_ON_ONCE(current->mm); + current->active_mm = &init_mm; + switch_mm(mm, &init_mm, current); + } +}I might be out of touch - doesn’t a flush already take place when we free the page-tables, at least on common cases on x86? IIUC exit_mmap() would free page-tables, and whenever page-tables are freed, on x86, we do shootdown regardless to whether the target CPU TLB state marks is_lazy. Then, flush_tlb_func() should call switch_mm_irqs_off() and everything should be fine, no? [ I understand you care about powerpc, just wondering on the effect on x86 ]
If you can easily piggyback on IPI work you already do in exit_mmap then that's likely to be preferable. I don't know the details of x86 these days but there is some discussion about it in last year's thread, it sounded quite feasible. This is stil required at final __mmdrop() time because it's still possible that lazy mm refs will need to be cleaned. exit_mmap() itself explicitly creates one, so if the __mmdrop() runs on a different CPU, then there's one. kthreads using the mm could create others. If that part of it is unclear or under-commented, I can try improve it. Thanks, Nick