On Tue, Jan 31, 2023 at 05:45:21AM +0000, Matthew Wilcox wrote: [...] > > I ran perf and it seems like percpu counter allocation is the additional > > cost with this patch. See the report below. However I made spawn a bit > > more sophisticated by adding a mmap() of a GiB then the page table > > copy became the significant cost and no difference without or with the > > given patch. > > > > I am now wondering if this fork ping pong really an important workload > > that we should revert the patch or ignore for now but work on improving > > the performance of __alloc_percpu_gfp code. > > > > > > - 90.97% 0.06% spawn [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe > > - 90.91% entry_SYSCALL_64_after_hwframe > > - 90.86% do_syscall_64 > > - 80.03% __x64_sys_clone > > - 79.98% kernel_clone > > - 75.97% copy_process > > + 46.04% perf_event_init_task > > - 21.50% copy_mm > > - 10.05% mm_init > > ----------------------> - 8.92% __percpu_counter_init > > - 8.67% __alloc_percpu_gfp > > - 5.70% pcpu_alloc > > 5.7% of our time spent in pcpu_alloc seems excessive. Are we contending > on pcpu_alloc_mutex perhaps? Also, are you doing this on a 4-socket > machine like the kernel test robot ran on? I ran on 2-socket machine and I am not sure about pcpu_alloc_mutex but I doubt that because I ran a single instance of the spawn test i.e. a single fork ping pong. > > We could cut down the number of calls to pcpu_alloc() by a factor of 4 > by having a pcpu_alloc_bulk() that would allocate all four RSS counters > at once. > > Just throwing out ideas ... Thanks, I will take a stab at pcpu_alloc_bulk() and will share the result tomorrow. thanks, Shakeel
