On Fri, Feb 21, 2025 at 12:52:21PM +0100, Sebastian Andrzej Siewior wrote:
> Using u64 for statistics can lead to inconsistency on 32bit because an
> update and a read requires to access two 32bit values.
> This can be avoided by using u64_stats_t for the counters and
> u64_stats_sync for the required synchronisation on 32bit platforms. The
> synchronisation is a NOP on 64bit architectures.
Same as in previous messages: I'd want to see clearly that this is
indeed an issue on 32bit systems showing before/after assembly.
> Use u64_stats_t for the counters in page_pool_recycle_stats.
Commit message says page_pool_recycle_stats, but code below is for
alloc stats.
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> ---
> .../ethernet/mellanox/mlx5/core/en_stats.c | 12 ++---
> include/net/page_pool/types.h | 14 +++---
> net/core/page_pool.c | 45 +++++++++++++------
> net/core/page_pool_user.c | 12 ++---
> 4 files changed, 52 insertions(+), 31 deletions(-)
[...]
> --- a/include/net/page_pool/types.h
> +++ b/include/net/page_pool/types.h
> @@ -96,6 +96,7 @@ struct page_pool_params {
> #ifdef CONFIG_PAGE_POOL_STATS
> /**
> * struct page_pool_alloc_stats - allocation statistics
> + * @syncp: synchronisations point for updates.
> * @fast: successful fast path allocations
> * @slow: slow path order-0 allocations
> * @slow_high_order: slow path high order allocations
> @@ -105,12 +106,13 @@ struct page_pool_params {
> * the cache due to a NUMA mismatch
> */
> struct page_pool_alloc_stats {
> - u64 fast;
> - u64 slow;
> - u64 slow_high_order;
> - u64 empty;
> - u64 refill;
> - u64 waive;
> + struct u64_stats_sync syncp;
> + u64_stats_t fast;
> + u64_stats_t slow;
> + u64_stats_t slow_high_order;
> + u64_stats_t empty;
> + u64_stats_t refill;
> + u64_stats_t waive;
> };
When I tried to get this in initially, Jesper had feelings about the
cacheline placement of the counters. I have no idea if that is still
the case or not.
My suggestion to you (assuming that your initial assertion is
correct that this_cpu_inc isn't safe on 32bit x86) would be to:
- include pahole output showing the placement of these counters
- include the same benchmarks I included in the original series
[1] that Jesper requested from me. I believe the code for the
benchmarks can be found here:
https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/lib
That would probably make it easier for the page pool people to
review / ack and would likely result in fewer revisions.
[1]: https://lore.kernel.org/all/1646172610-129397-1-git-send-email-jdamato@xxxxxxxxxx/
