Re: [PATCH net-next v2 00/10] Replace page_frag with page_frag_cache (Part-2)

[Alexander Duyck <alexander.duyck@gmail.com>]

On Fri, Dec 6, 2024 at 4:32 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> This is part 2 of "Replace page_frag with page_frag_cache",
> which introduces the new API and replaces page_frag with
> page_frag_cache for sk_page_frag().
>
> The part 1 of "Replace page_frag with page_frag_cache" is in
> [1].
>
> After [2], there are still two implementations for page frag:
>
> 1. mm/page_alloc.c: net stack seems to be using it in the
>    rx part with 'struct page_frag_cache' and the main API
>    being page_frag_alloc_align().
> 2. net/core/sock.c: net stack seems to be using it in the
>    tx part with 'struct page_frag' and the main API being
>    skb_page_frag_refill().
>
> This patchset tries to unfiy the page frag implementation
> by replacing page_frag with page_frag_cache for sk_page_frag()
> first. net_high_order_alloc_disable_key for the implementation
> in net/core/sock.c doesn't seems matter that much now as pcp
> is also supported for high-order pages:
> commit 44042b449872 ("mm/page_alloc: allow high-order pages to
> be stored on the per-cpu lists")
>
> As the related change is mostly related to networking, so
> targeting the net-next. And will try to replace the rest
> of page_frag in the follow patchset.
>
> After this patchset:
> 1. Unify the page frag implementation by taking the best out of
>    two the existing implementations: we are able to save some space
>    for the 'page_frag_cache' API user, and avoid 'get_page()' for
>    the old 'page_frag' API user.
> 2. Future bugfix and performance can be done in one place, hence
>    improving maintainability of page_frag's implementation.
>
> Performance validation for part2:
> 1. Using micro-benchmark ko added in patch 1 to test aligned and
>    non-aligned API performance impact for the existing users, there
>    seems to be about 20% performance degradation for refactoring
>    page_frag to support the new API, which seems to nullify most of
>    the performance gain in [3] of part1.

So if I am understanding correctly then this is showing a 20%
performance degradation with this patchset. I would argue that it is
significant enough that it would be a blocking factor for this patch
set. I would suggest bisecting the patch set to identify where the
performance degradation has been added and see what we can do to
resolve it, and if nothing else document it in that patch so we can
identify the root cause for the slowdown.

> 2. Use the below netcat test case, there seems to be some minor
>    performance gain for replacing 'page_frag' with 'page_frag_cache'
>    using the new page_frag API after this patchset.
>    server: taskset -c 32 nc -l -k 1234 > /dev/null
>    client: perf stat -r 200 -- taskset -c 0 head -c 20G /dev/zero | taskset -c 1 nc 127.0.0.1 1234

This test would barely touch the page pool. The fact is most of the
overhead for this would likely be things like TCP latency and data
copy much more than the page allocation. As such fluctuations here are
likely not related to your changes.