[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h835kskx.fsf@toke.dk>
Date: Fri, 15 Nov 2019 17:33:18 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: netdev@...r.kernel.org,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Matteo Croce <mcroce@...hat.com>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [net-next v1 PATCH 2/4] page_pool: add destroy attempts counter and rename tracepoint
Jesper Dangaard Brouer <brouer@...hat.com> writes:
> When Jonathan change the page_pool to become responsible to its
> own shutdown via deferred work queue, then the disconnect_cnt
> counter was removed from xdp memory model tracepoint.
>
> This patch change the page_pool_inflight tracepoint name to
> page_pool_release, because it reflects the new responsability
> better. And it reintroduces a counter that reflect the number of
> times page_pool_release have been tried.
>
> The counter is also used by the code, to only empty the alloc
> cache once. With a stuck work queue running every second and
> counter being 64-bit, it will overrun in approx 584 billion
> years. For comparison, Earth lifetime expectancy is 7.5 billion
> years, before the Sun will engulf, and destroy, the Earth.
I love how you just casually threw that last bit in there; and now I'm
thinking about under which conditions that would not be enough. Maybe
someone will put this code on a space probe bound for interstellar
space, which will escape the death of our solar system only to be
destined to increment this counter forever in the cold, dead void of
space?
I think that is a risk we can live with, so:
Acked-by: Toke Høiland-Jørgensen <toke@...hat.com>
Powered by blists - more mailing lists