[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZDqHmCX7D4aXOQzl@lore-desk>
Date: Sat, 15 Apr 2023 13:16:40 +0200
From: Lorenzo Bianconi <lorenzo@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, hawk@...nel.org,
ilias.apalodimas@...aro.org, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com,
lorenzo.bianconi@...hat.com, jdamato@...tly.com
Subject: Re: [PATCH net-next] net: page_pool: add pages and released_pages
counters
> On Thu, 13 Apr 2023 23:46:03 +0200 Lorenzo Bianconi wrote:
> > @@ -411,6 +417,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
> > pool->pages_state_hold_cnt++;
> > trace_page_pool_state_hold(pool, page,
> > pool->pages_state_hold_cnt);
> > + alloc_stat_inc(pool, pages);
> > }
> >
> > /* Return last page */
>
> What about high order? If we use bulk API for high order one day,
> will @slow_high_order not count calls like @slow does? So we should
> bump the new counter for high order, too.
yes, right. AFAIU "slow_high_order" and "slow" just count number of
pages returned to the pool consumer and not the number of pages
allocated to the pool (as you said, since we do not use bulking
for high_order allocation there is no difference at the moment).
What I would like to track is the number of allocated pages
(of any order) so I guess we can just increment "pages" counter in
__page_pool_alloc_page_order() as well. Agree?
>
> Which makes it very similar to pages_state_hold_cnt, just 64bit...
do you prefer to use pages_state_hold_cnt instead of adding a new
pages counter?
Regards,
Lorenzo
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists