[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a57d3dde-ac45-be9c-5c16-263415060334@cybernetics.com>
Date: Tue, 31 May 2022 15:52:40 -0400
From: Tony Battersby <tonyb@...ernetics.com>
To: Robin Murphy <robin.murphy@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: iommu@...ts.linux-foundation.org, kernel-team@...com,
Matthew Wilcox <willy@...radead.org>,
Keith Busch <kbusch@...nel.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 04/10] dmapool: improve accuracy of debug statistics
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.
Tony
Powered by blists - more mailing lists