Re: [PATCH] mm, page_alloc: batch cma update on pcp buffer refill

[Vlastimil Babka]

On 3/3/23 13:52, Alexander Halbuer wrote:
> On 2/21/23 11:27, Vlastimil Babka wrote:
>> Incidentally, did you observe any improvements by [2] with your test,
>> especially as the batch freeing side also no longer does checking under zone
>> lock?
>> 
>> Thanks!
>> 
> 
> I finally managed to repeat the benchmark to see the effects of
> disabling alloc and free sanity checks by default ("mm, page_alloc:
> reduce page alloc/free sanity checks"; results below).

Thanks for the measurements!

> Average huge page allocation latency drastically reduces by over 90% in
> the single core case. However i can't see any real improvements for the
> free operation.

Ah, I see now why huge page freeing didn't improve. It's because
bulkfree_pcp_prepare() was calling free_page_is_bad(page) thus checking just
the head page. So the tail pages were not actually checked. Just another
detail of how the checking wasn't thorough anyway.

> ---
> 
> Measurement results for the batch allocation benchmark for different
> core counts: Internally used functions are alloc_pages_node() for
> allocation (get) and __free_pages() for free (put).
> 
> Compared kernel versions are from the mm-unstable branch:
> - Reference version (without the mentioned patch):
> daf4bcbf2b72 ("mm: cma: make kobj_type structure constant")
> - Patched version:
> 60114678f165 ("mm-page_alloc-reduce-page-alloc-free-sanity-checks-fix")
> 
> Normale pages
> +-------+------+-------+---------+------+-------+---------+
> | cores | base | patch |    diff | base | patch |  diff   |
> |       |  get |   get |     get |  put |   put |   put   |
> |       | (ns) |  (ns) |         | (ns) |  (ns) |         |
> +-------+------+-------+---------+------+-------+---------+
> |     1 |  122 |   118 | (-3.3%) |  118 |   116 | (-1.7%) |
> |     2 |  133 |   130 | (-2.3%) |  130 |   123 | (-5.4%) |
> |     3 |  136 |   132 | (-2.9%) |  175 |   162 | (-7.4%) |
> |     4 |  161 |   149 | (-7.5%) |  241 |   226 | (-6.2%) |
> |     6 |  247 |   228 | (-7.7%) |  366 |   344 | (-6.0%) |
> |     8 |  331 |   304 | (-8.2%) |  484 |   456 | (-5.8%) |
> |    10 |  416 |   390 | (-6.2%) |  615 |   578 | (-6.0%) |
> |    12 |  502 |   472 | (-6.0%) |  727 |   687 | (-5.5%) |
> |    14 |  584 |   552 | (-5.5%) |  862 |   816 | (-5.3%) |
> |    16 |  669 |   632 | (-5.5%) |  967 |   923 | (-4.6%) |
> |    20 |  833 |   787 | (-5.5%) | 1232 |  1164 | (-5.5%) |
> |    24 |  999 |   944 | (-5.5%) | 1462 |  1384 | (-5.3%) |
> +-------+------+-------+---------+------+-------+---------+
> 
> Huge Pages
> +-------+------+-------+----------+-------+-------+---------+
> | cores | base | patch |     diff |  base | patch |  diff   |
> |       |  get |   get |      get |   put |   put |   put   |
> |       | (ns) |  (ns) |          |  (ns) |  (ns) |         |
> +-------+------+-------+----------+-------+-------+---------+
> |     1 | 3148 |   177 | (-94.4%) |  2946 |  2872 | (-2.5%) |
> |     2 | 3404 |   596 | (-82.5%) |  3318 |  3306 | (-0.4%) |
> |     3 | 3581 |   950 | (-73.5%) |  3401 |  3358 | (-1.3%) |
> |     4 | 3651 |  1284 | (-64.8%) |  3562 |  3616 | (1.5%)  |
> |     6 | 3568 |  1929 | (-45.9%) |  4478 |  4564 | (1.9%)  |
> |     8 | 3605 |  2328 | (-35.4%) |  5658 |  5546 | (-2.0%) |
> |    10 | 4093 |  2935 | (-28.3%) |  6758 |  6457 | (-4.5%) |
> |    12 | 4778 |  3540 | (-25.9%) |  7698 |  7565 | (-1.7%) |
> |    14 | 5565 |  4097 | (-26.4%) |  8748 |  8810 | (0.7%)  |
> |    16 | 6364 |  4725 | (-25.8%) |  9942 | 10103 | (1.6%)  |
> |    20 | 8014 |  5915 | (-26.2%) | 12509 | 12772 | (2.1%)  |
> |    24 | 8732 |  7138 | (-18.3%) | 15217 | 15433 | (1.4%)  |
> +-------+------+-------+----------+-------+-------+---------+
> 
>>>
>>> [1] https://lore.kernel.org/lkml/1d468148-936f-8816-eb71-1662f2d4945b@xxxxxxx/
>>> [2] https://lore.kernel.org/linux-mm/20230216095131.17336-1-vbabka@xxxxxxx/