mbox series

[PATCHv4,00/12] dmapool enhancements

Message ID 20230126215125.4069751-1-kbusch@meta.com (mailing list archive)
Headers show
Series dmapool enhancements | expand

Message

Keith Busch Jan. 26, 2023, 9:51 p.m. UTC 
From: Keith Busch <kbusch@kernel.org>

Time spent in dma_pool alloc/free increases linearly with the number of
pages backing the pool. We can reduce this to constant time with minor
changes to how free pages are tracked.

Changes since v4:

  Added received reviews

  Applied comments from Christoph:
    Combined all debug code in one #ifdef block
    Fixed some whitespace
    
Keith Busch (8):
  dmapool: add alloc/free performance test
  dmapool: move debug code to own functions
  dmapool: rearrange page alloc failure handling
  dmapool: consolidate page initialization
  dmapool: simplify freeing
  dmapool: don't memset on free twice
  dmapool: link blocks across pages
  dmapool: create/destroy cleanup

Tony Battersby (4):
  dmapool: remove checks for dev == NULL
  dmapool: use sysfs_emit() instead of scnprintf()
  dmapool: cleanup integer types
  dmapool: speedup DMAPOOL_DEBUG with init_on_alloc

 mm/Kconfig        |   9 ++
 mm/Makefile       |   1 +
 mm/dmapool.c      | 402 ++++++++++++++++++++++------------------------
 mm/dmapool_test.c | 147 +++++++++++++++++
 4 files changed, 350 insertions(+), 209 deletions(-)
 create mode 100644 mm/dmapool_test.c

Comments

Andrew Morton Jan. 26, 2023, 10:22 p.m. UTC | #1 
On Thu, 26 Jan 2023 13:51:13 -0800 Keith Busch <kbusch@meta.com> wrote:

> Time spent in dma_pool alloc/free increases linearly with the number of
> pages backing the pool. We can reduce this to constant time with minor
> changes to how free pages are tracked.

Do we have any performance testing results for realistic workloads?
Keith Busch Jan. 27, 2023, 12:27 a.m. UTC | #2 
On Thu, Jan 26, 2023 at 02:22:09PM -0800, Andrew Morton wrote:
> On Thu, 26 Jan 2023 13:51:13 -0800 Keith Busch <kbusch@meta.com> wrote:
> 
> > Time spent in dma_pool alloc/free increases linearly with the number of
> > pages backing the pool. We can reduce this to constant time with minor
> > changes to how free pages are tracked.
> 
> Do we have any performance testing results for realistic workloads?

Yes, I mentioned this a little in patch 11, profiling with nvme with high-depth
dmapool allocating workloads. Results really depend on your environment, so
YMMV, but I was able to observe time spent in dma_pool_{alloc,free}() reduced
by half.