Messages in this thread | | | Date | Thu, 30 Jun 2022 09:52:12 +0100 | Subject | Re: [RFC PATCH] mm/slub: enable debugging memory wasting of kmalloc | From | Robin Murphy <> |
| |
On 2022-06-30 03:47, Andrew Morton wrote: > On Thu, 30 Jun 2022 10:38:44 +0800 Feng Tang <feng.tang@intel.com> wrote: > >> Hi Andrew, >> >> Thanks for the review! >> >> On Wed, Jun 29, 2022 at 07:30:06PM -0700, Andrew Morton wrote: >>> On Thu, 30 Jun 2022 09:47:15 +0800 Feng Tang <feng.tang@intel.com> wrote: >>> >>>> kmalloc's API family is critical for mm, with one shortcoming that >>>> its object size is fixed to be power of 2. When user requests memory >>>> for '2^n + 1' bytes, actually 2^(n+1) bytes will be allocated, so >>>> in worst case, there is around 50% memory space waste. >>>> >>>> We've met a kernel boot OOM panic, and from the dumped slab info: >>>> >>>> [ 26.062145] kmalloc-2k 814056KB 814056KB >>>> >>>> >From debug we found there are huge number of 'struct iova_magazine', >>>> whose size is 1032 bytes (1024 + 8), so each allocation will waste >>>> 1016 bytes. Though the issue is solved by giving the right(bigger) >>>> size of RAM, it is still better to optimize the size (either use >>>> a kmalloc friendly size or create a dedicated slab for it). >>> >>> Well that's nice, and additional visibility is presumably a good thing. >>> >>> But what the heck is going on with iova_magazine? Is anyone looking at >>> moderating its impact? >> >> Yes, I have a very simple patch at hand >> >> --- a/drivers/iommu/iova.c >> +++ b/drivers/iommu/iova.c >> @@ -614,7 +614,7 @@ EXPORT_SYMBOL_GPL(reserve_iova); >> * dynamic size tuning described in the paper. >> */ >> >> -#define IOVA_MAG_SIZE 128 >> +#define IOVA_MAG_SIZE 127 > > Well OK. Would benefit from a comment explaining the reasoning. > > But we still have eleventy squillion of these things in flight. Why?
They're storage for a per-CPU caching scheme - for n CPUs, there should currently be (2n + 32) * 6 in flight, since there's one set for each of 6 sizes. The 32 really should be n or 2n as well since it's needlessly large for small systems and a bottleneck for large ones, but it needs some unpicking to allow for dynamic allocations.
Thanks, Robin.
| |