1. 11 Dec, 2018 7 commits
    • Robin Murphy's avatar
      dma-debug: Batch dma_debug_entry allocation · ad78dee0
      Robin Murphy authored
      DMA debug entries are one of those things which aren't that useful
      individually - we will always want some larger quantity of them - and
      which we don't really need to manage the exact number of - we only care
      about having 'enough'. In that regard, the current behaviour of creating
      them one-by-one leads to a lot of unwarranted function call overhead and
      memory wasted on alignment padding.
      
      Now that we don't have to worry about freeing anything via
      dma_debug_resize_entries(), we can optimise the allocation behaviour by
      grabbing whole pages at once, which will save considerably on the
      aforementioned overheads, and probably offer a little more cache/TLB
      locality benefit for traversing the lists under normal operation. This
      should also give even less reason for an architecture-level override of
      the preallocation size, so make the definition unconditional - if there
      is still any desire to change the compile-time value for some platforms
      it would be better off as a Kconfig option anyway.
      
      Since freeing a whole page of entries at once becomes enough of a
      challenge that it's not really worth complicating dma_debug_init(), we
      may as well tweak the preallocation behaviour such that as long as we
      manage to allocate *some* pages, we can leave debugging enabled on a
      best-effort basis rather than otherwise wasting them.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      ad78dee0
    • Robin Murphy's avatar
      dma/debug: Remove dma_debug_resize_entries() · 0cb0e25e
      Robin Murphy authored
      With the only caller now gone, we can clean up this part of dma-debug's
      exposed internals and make way to tweak the allocation behaviour.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      0cb0e25e
    • Robin Murphy's avatar
      x86/dma/amd-gart: Stop resizing dma_debug_entry pool · a8a4c98f
      Robin Murphy authored
      dma-debug is now capable of adding new entries to its pool on-demand if
      the initial preallocation was insufficient, so the IOMMU_LEAK logic no
      longer needs to explicitly change the pool size. This does lose it the
      ability to save a couple of megabytes of RAM by reducing the pool size
      below its default, but it seems unlikely that that is a realistic
      concern these days (or indeed that anyone is actively debugging AGP
      drivers' DMA usage any more). Getting rid of dma_debug_resize_entries()
      will make room for further streamlining in the dma-debug code itself.
      
      Removing the call reveals quite a lot of cruft which has been useless
      for nearly a decade since commit 19c1a6f5 ("x86 gart: reimplement
      IOMMU_LEAK feature by using DMA_API_DEBUG"), including the entire
      'iommu=leak' parameter, which controlled nothing except whether
      dma_debug_resize_entries() was called or not.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      a8a4c98f
    • Robin Murphy's avatar
      dma-debug: Make leak-like behaviour apparent · ceb51173
      Robin Murphy authored
      Now that we can dynamically allocate DMA debug entries to cope with
      drivers maintaining excessively large numbers of live mappings, a driver
      which *does* actually have a bug leaking mappings (and is not unloaded)
      will no longer trigger the "DMA-API: debugging out of memory - disabling"
      message until it gets to actual kernel OOM conditions, which means it
      could go unnoticed for a while. To that end, let's inform the user each
      time the pool has grown to a multiple of its initial size, which should
      make it apparent that they either have a leak or might want to increase
      the preallocation size.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      ceb51173
    • Robin Murphy's avatar
      dma-debug: Dynamically expand the dma_debug_entry pool · 2b9d9ac0
      Robin Murphy authored
      Certain drivers such as large multi-queue network adapters can use pools
      of mapped DMA buffers larger than the default dma_debug_entry pool of
      65536 entries, with the result that merely probing such a device can
      cause DMA debug to disable itself during boot unless explicitly given an
      appropriate "dma_debug_entries=..." option.
      
      Developers trying to debug some other driver on such a system may not be
      immediately aware of this, and at worst it can hide bugs if they fail to
      realise that dma-debug has already disabled itself unexpectedly by the
      time their code of interest gets to run. Even once they do realise, it
      can be a bit of a pain to emprirically determine a suitable number of
      preallocated entries to configure, short of massively over-allocating.
      
      There's really no need for such a static limit, though, since we can
      quite easily expand the pool at runtime in those rare cases that the
      preallocated entries are insufficient, which is arguably the least
      surprising and most useful behaviour. To that end, refactor the
      prealloc_memory() logic a little bit to generalise it for runtime
      reallocations as well.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      2b9d9ac0
    • Robin Murphy's avatar
      dma-debug: Use pr_fmt() · f737b095
      Robin Murphy authored
      Use pr_fmt() to generate the "DMA-API: " prefix consistently. This
      results in it being added to a couple of pr_*() messages which were
      missing it before, and for the err_printk() calls moves it to the actual
      start of the message instead of somewhere in the middle.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      f737b095
    • Robin Murphy's avatar
      dma-debug: Expose nr_total_entries in debugfs · 9f191555
      Robin Murphy authored
      Expose nr_total_entries in debugfs, so that {num,min}_free_entries
      become even more meaningful to users interested in current/maximum
      utilisation. This becomes even more relevant once nr_total_entries
      may change at runtime beyond just the existing AMD GART debug code.
      Suggested-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      9f191555
  2. 06 Dec, 2018 24 commits
  3. 05 Dec, 2018 1 commit
  4. 01 Dec, 2018 8 commits