Re: [PATCH 04/10] dmapool: improve accuracy of debug statistics

[Robin Murphy]

On 2022-05-31 20:52, Tony Battersby wrote:
> On 5/31/22 15:48, Robin Murphy wrote:
> > On 2022-05-31 19:17, Tony Battersby wrote:
> >
> > >    				 pool->name, blocks,
> > > -				 (size_t) pages *
> > > -				 (pool->allocation / pool->size),
> > > +				 (size_t) pages * pool->blks_per_alloc,
> > >    				 pool->size, pages);
> > >    		size -= temp;
> > >    		next += temp;
> > > @@ -168,6 +168,9 @@ struct dma_pool *dma_pool_create(const char *name, struct device *dev,
> > >    	retval->size = size;
> > >    	retval->boundary = boundary;
> > >    	retval->allocation = allocation;
> > > +	retval->blks_per_alloc =
> > > +		(allocation / boundary) * (boundary / size) +
> > > +		(allocation % boundary) / size;
> > Do we really need to store this? Sure, 4 divisions (which could possibly
> > be fewer given the constraints on boundary) isn't the absolute cheapest
> > calculation, but I still can't imagine anyone would be polling sysfs
> > stats hard enough to even notice.
> The stored value is also used in patch #5, in more performance-critical
> code, although only when debug is enabled.

Ah, fair enough. On second look I think 64-bit systems could effectively 
store this for free anyway, if patch #2 moved "size" down past "dev" in 
struct dma_pool, such that blks_per_alloc then ends up padding out the 
hole again.

FWIW the mathematician in me also now can't help seeing the algebraic 
reduction to at least "(allocation + (allocation % boundary)) / size", 
but is now too tired to reason about the power-of-two constraints and 
whether the intermediate integer truncations matter...

Cheers,
Robin.