On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote: > 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. To minimize that impact, place VMAs into > a list and free them in groups using one call_rcu() call per group. After some more clarification I can understand how call_rcu might not be super happy about thousands of callbacks to be invoked and I do agree that this is not really optimal. On the other hand I do not like this solution much either. VM_AREA_FREE_LIST_MAX is arbitrary and it won't really help all that much with processes with a huge number of vmas either. It would still be in housands of callbacks to be scheduled without a good reason. Instead, are there any other cases than remove_vma that need this batching? We could easily just link all the vmas into linked list and use a single call_rcu instead, no? This would both simplify the implementation, remove the scaling issue as well and we do not have to argue whether VM_AREA_FREE_LIST_MAX should be epsilon or epsilon + 1. -- Michal Hocko SUSE Labs
