Re: [linux-next:master] [vmalloc] 60ced5818f: stress-ng.shm.ops_per_sec 7.2% regression

>>> -- 
>>> 0-DAY CI Kernel Test Service
>>> https://github.com/intel/lkp-tests/wiki
>>
>> Thanks. I'll check it.

Thanks for digging into the details!

> 
> Looking at the patch [1], the regression reported by lkp [2] appears to
> be caused by a lack of order-0 pages in the PCP lists,
> which increases zone-locked allocations (mm_page_alloc_zone_locked).
> 
> On my reproduced setup (an x86_64 workstation), most pages freed through
> free_pages_bulk() were order-2 pages (nr_pages == 4), including
> vmalloc-backed stacks. With patch [1], these order-2 pages are returned to
> the order-2 PCP lists, unlike commit 4aa4abf1f1 (“mm/page_alloc: optimize free_contig_range()”),
> which effectively populated the order-0 PCP lists.
> 
> Since the shmem workload appears to fault memory at PAGE_SIZE granularity,
> the reduced availability of order-0 pages in PCP lists seems to increase
> zone-locked order-0 allocations, which may explain the regression observed by lkp.
> 
> Performance comparison (5 runs):
>   - perf stat -e 'kmem:mm_page_alloc_extfrag' --filter 'alloc_order == 0' \
>               -e 'kmem:mm_page_alloc_zone_locked' --filter 'order == 0' \
>               -e 'kmem:mm_page_alloc' --filter 'order == 0' -- ./repro-script
> 
> Metric                               4aa4abf1f1           60ced5818f        Difference
> 
> ------------------------------------------------------------------------------------------
> 
> Zone-locked Allocation Ratio (%)     46.39 ± 0.17%       48.31 ± 0.37%       +1.92 pp
> 
>   - Ratio = (mm_page_alloc_extfrag + mm_page_alloc_zone_locked) / mm_page_alloc × 100
>   - Values are reported as median ± relative half-range across three runs.
> 
> The shmem test appears to handle page faults at PAGE_SIZE granularity, which seems to amplify the impact of the reduced availability of order-0 pages.

Okay, so less fragmentation in the PCP results in fallback to the buddy for
order-0. Given that we don't split in the PCP and fallback to the buddy, that
makes sense.

> 
> 
> As an experiment, I modified free_pages_bulk() to free pages individually
> as order-0 pages when nr_contig <= (1 << PAGE_ALLOC_COSTLY_ORDER).
> This restores behavior closer to 4aa4abf1f1 and results in almost
> no difference compared to that commit.
> 
> Performance comparison (5 runs)
>   - ./repro-script
> 
> Metric                     4aa4abf1f1            change             Difference
> ----------------------------------------------------------------------------------
> bogo_ops                   656,513 ± 0.34%      656,488 ± 0.23%          -25
> 
> bogo_ops/s (realtime)      10,935.95 ± 0.34%    10,935.86 ± 0.23%      -0.09
> 
> bogo_ops/s (usr+sys time)     220.31 ± 0.40%       219.30 ± 0.21%      -1.01
> 
> The differences are negligible and essentially restore the performance
> observed with 4aa4abf1f1.

Makes sense.

Looking at the original results, I spotted

    354997 ± 14%    +111.6%     751255 ±  4%  meminfo.PageTables

So we consumed twice the (process) page tables. Did you also manage to reproduce
that or do you have an explanation for that?

> 
> Given that the regression appears to be driven by a synthetic workload that
> combines frequent shmem page faults with repeated stack allocation/free operations,
> I do not think this is a significant concern for typical real-world workloads.

Yeah, if it's "we have less fragmentation", I agree. Using order-2 folios for
shmem would likely similarly mitigate the problem I assume.

-- 
Cheers,

David