Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-19 Thread Marcelo Tosatti
On Wed, Apr 19, 2023 at 01:30:57PM +0200, David Hildenbrand wrote: > On 06.04.23 20:27, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 05:51:52PM +0200, David Hildenbrand wrote: > > > On 06.04.23 17:02, Peter Zijlstra wrote: > > > > > > DavidH, what do you thikn about reviving Jann's patches

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-19 Thread David Hildenbrand
On 06.04.23 20:27, Peter Zijlstra wrote: On Thu, Apr 06, 2023 at 05:51:52PM +0200, David Hildenbrand wrote: On 06.04.23 17:02, Peter Zijlstra wrote: DavidH, what do you thikn about reviving Jann's patches here: https://bugs.chromium.org/p/project-zero/issues/detail?id=2365#c1 Those are

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-19 Thread Marcelo Tosatti
On Thu, Apr 06, 2023 at 03:32:06PM +0200, Peter Zijlstra wrote: > On Thu, Apr 06, 2023 at 09:49:22AM -0300, Marcelo Tosatti wrote: > > > > > 2) Depends on the application and the definition of "occasional". > > > > > > > > For certain types of applications (for example PLC software or > > > >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 05:51:52PM +0200, David Hildenbrand wrote: > On 06.04.23 17:02, Peter Zijlstra wrote: > > DavidH, what do you thikn about reviving Jann's patches here: > > > >https://bugs.chromium.org/p/project-zero/issues/detail?id=2365#c1 > > > > Those are far more invasive, but

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread David Hildenbrand
On 06.04.23 17:02, Peter Zijlstra wrote: On Thu, Apr 06, 2023 at 04:04:23PM +0200, Peter Zijlstra wrote: On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: To actually hit this path you're doing something really

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 04:42:02PM +0200, David Hildenbrand wrote: > On 06.04.23 16:04, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > > > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > > > > > To actually hit this path you're

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 04:04:23PM +0200, Peter Zijlstra wrote: > On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > > > To actually hit this path you're doing something really dodgy. > > > > > > Apparently

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread David Hildenbrand
On 06.04.23 16:04, Peter Zijlstra wrote: On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: To actually hit this path you're doing something really dodgy. Apparently khugepaged is using the same infrastructure: $

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 03:11:52PM +0100, Valentin Schneider wrote: > On 06/04/23 15:38, Peter Zijlstra wrote: > > On Wed, Apr 05, 2023 at 01:45:02PM +0100, Valentin Schneider wrote: > >> > >> I've been hacking on something like this (CSD deferral for NOHZ-full), > >> and unfortunately this uses

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Valentin Schneider
On 06/04/23 15:38, Peter Zijlstra wrote: > On Wed, Apr 05, 2023 at 01:45:02PM +0100, Valentin Schneider wrote: >> >> I've been hacking on something like this (CSD deferral for NOHZ-full), >> and unfortunately this uses the CPU-local cfd_data storage thing, which >> means any further

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > To actually hit this path you're doing something really dodgy. > > > > Apparently khugepaged is using the same infrastructure: > > > > $ grep

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 01:45:02PM +0100, Valentin Schneider wrote: > On 05/04/23 14:05, Frederic Weisbecker wrote: > > static void smp_call_function_many_cond(const struct cpumask *mask, > > smp_call_func_t func, void *info, > > @@ -946,10 +948,13 @@ static

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 09:49:22AM -0300, Marcelo Tosatti wrote: > > > 2) Depends on the application and the definition of "occasional". > > > > > > For certain types of applications (for example PLC software or > > > RAN processing), upon occurrence of an event, it is necessary to > > >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > To actually hit this path you're doing something really dodgy. > > Apparently khugepaged is using the same infrastructure: > > $ grep tlb_remove_table khugepaged.c > tlb_remove_table_sync_one(); >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Marcelo Tosatti
On Wed, Apr 05, 2023 at 09:54:57PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2023 at 04:43:14PM -0300, Marcelo Tosatti wrote: > > > Two points: > > > > 1) For a virtualized system, the overhead is not only of executing the > > IPI but: > > > > VM-exit > > run VM-exit code in host >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Marcelo Tosatti
On Wed, Apr 05, 2023 at 09:52:26PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2023 at 04:45:32PM -0300, Marcelo Tosatti wrote: > > On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > > > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > > > On Tue, Apr

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 04:43:14PM -0300, Marcelo Tosatti wrote: > Two points: > > 1) For a virtualized system, the overhead is not only of executing the > IPI but: > > VM-exit > run VM-exit code in host > handle IPI > run VM-entry code in host > VM-entry I

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 04:45:32PM -0300, Marcelo Tosatti wrote: > On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > > > + int

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Marcelo Tosatti
On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > > + int state = atomic_read(>state); > > > + /* will return true only for cpus in

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Marcelo Tosatti
On Wed, Apr 05, 2023 at 12:43:58PM +0200, Frederic Weisbecker wrote: > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > @@ -191,6 +192,20 @@ static void tlb_remove_table_smp_sync(void *arg) > > /* Simply deliver the interrupt */ > > } > > > > + > > +#ifdef

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Valentin Schneider
On 05/04/23 14:05, Frederic Weisbecker wrote: > static void smp_call_function_many_cond(const struct cpumask *mask, > smp_call_func_t func, void *info, > @@ -946,10 +948,13 @@ static void smp_call_function_many_cond(const struct > cpumask *mask, > #endif >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Wed, Apr 05, 2023 at 02:05:13PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 05, 2023 at 01:41:48PM +0200, Peter Zijlstra wrote: > 1) It has the advantage to check context tracking _after_ the llist_add(), so >it really can't be misused ordering-wise. > > 2) The IPI callback is always

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Wed, Apr 05, 2023 at 01:41:48PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > > > + int

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread David Hildenbrand
On 05.04.23 13:41, Peter Zijlstra wrote: On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: + int state = atomic_read(>state); + /*

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > > + int state = atomic_read(>state); > > > + /* will return true only for cpus in

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > + int state = atomic_read(>state); > > + /* will return true only for cpus in kernel space */ > > + return state & CT_STATE_MASK == CONTEXT_KERNEL; > > +}

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > @@ -191,6 +192,20 @@ static void tlb_remove_table_smp_sync(void *arg) > /* Simply deliver the interrupt */ > } > > + > +#ifdef CONFIG_CONTEXT_TRACKING > +static bool cpu_in_kernel(int cpu, void *info) > +{ > + struct

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-04 Thread Peter Zijlstra
On Tue, Apr 04, 2023 at 05:12:17PM +0200, Peter Zijlstra wrote: > > case 2: > > CPU-A CPU-B > > > > modify pagetables > > tlb_flush (memory barrier) > > state == CONTEXT_USER > > int state =

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-04 Thread Peter Zijlstra
On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > The tlb_remove_table_smp_sync IPI is used to ensure the outdated tlb page > is not currently being accessed and can be cleared. > This occurs once all CPUs have left the lockless gup code section. > If they reenter the page table

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-04 Thread David Hildenbrand
On 04.04.23 15:42, Yair Podemsky wrote: The tlb_remove_table_smp_sync IPI is used to ensure the outdated tlb page is not currently being accessed and can be cleared. This occurs once all CPUs have left the lockless gup code section. If they reenter the page table walk, the pointers will be to