On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko [off-list ref] wrote:

On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:

quoted

On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko [off-list ref] wrote:

quoted

On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:

quoted

call_rcu() can take a long time when callback offloading is enabled.
Its use in the vm_area_free can cause regressions in the exit path when
multiple VMAs are being freed.

What kind of regressions.

quoted

To minimize that impact, place VMAs into
a list and free them in groups using one call_rcu() call per group.

Please add some data to justify this additional complexity.

Sorry, should have done that in the first place. A 4.3% regression was
noticed when running execl test from unixbench suite. spawn test also
showed 1.6% regression. Profiling revealed that vma freeing was taking
longer due to call_rcu() which is slow when RCU callback offloading is
enabled.

Could you be more specific? vma freeing is async with the RCU so how
come this has resulted in a regression? Is there any heavy
rcu_synchronize in the exec path? That would be an interesting
information.

No, there is no heavy rcu_synchronize() or any other additional
synchronous load in the exit path. It's the call_rcu() which can block
the caller if CONFIG_RCU_NOCB_CPU is enabled and there are lots of
other call_rcu()'s going on in parallel. Note that call_rcu() calls
rcu_nocb_try_bypass() if CONFIG_RCU_NOCB_CPU is enabled and profiling
revealed that this function was taking multiple ms (don't recall the
actual number, sorry). Paul's explanation implied that this happens
due to contention on the locks taken in this function. For more
in-depth details I'll have to ask Paul for help :) This code is quite
complex and I don't know all the details of RCU implementation.

--
Michal Hocko
SUSE Labs