lkml.org 
[lkml]   [2022]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 04/10] dmapool: improve accuracy of debug statistics
From
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.

\
 
 \ /
  Last update: 2022-05-31 23:57    [W:0.092 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site