* [PATCH] dma-pool: Fix too large DMA pools on medium systems @ 2020-06-08 8:52 Geert Uytterhoeven 2020-06-08 12:03 ` Robin Murphy 0 siblings, 1 reply; 4+ messages in thread From: Geert Uytterhoeven @ 2020-06-08 8:52 UTC (permalink / raw) To: Christoph Hellwig, Marek Szyprowski, Robin Murphy, David Rientjes Cc: iommu, Geert Uytterhoeven, linux-kernel On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA memory pools are much larger than intended (e.g. 2 MiB instead of 128 KiB on a 256 MiB system). Fix this by correcting the calculation of the number of GiBs of RAM in the system. Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size with memory capacity") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- kernel/dma/pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c index 35bb51c31fff370f..1c7eab2cc0498003 100644 --- a/kernel/dma/pool.c +++ b/kernel/dma/pool.c @@ -175,8 +175,8 @@ static int __init dma_atomic_pool_init(void) * sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1. */ if (!atomic_pool_size) { - atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) * - SZ_128K; + unsigned long gigs = totalram_pages() >> (30 - PAGE_SHIFT); + atomic_pool_size = max(gigs, 1UL) * SZ_128K; atomic_pool_size = min_t(size_t, atomic_pool_size, 1 << (PAGE_SHIFT + MAX_ORDER-1)); } -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] dma-pool: Fix too large DMA pools on medium systems 2020-06-08 8:52 [PATCH] dma-pool: Fix too large DMA pools on medium systems Geert Uytterhoeven @ 2020-06-08 12:03 ` Robin Murphy 2020-06-08 12:25 ` Geert Uytterhoeven 0 siblings, 1 reply; 4+ messages in thread From: Robin Murphy @ 2020-06-08 12:03 UTC (permalink / raw) To: Geert Uytterhoeven, Christoph Hellwig, Marek Szyprowski, David Rientjes Cc: iommu, linux-kernel On 2020-06-08 09:52, Geert Uytterhoeven wrote: > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA > memory pools are much larger than intended (e.g. 2 MiB instead of 128 > KiB on a 256 MiB system). > > Fix this by correcting the calculation of the number of GiBs of RAM in > the system. > > Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size with memory capacity") > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > --- > kernel/dma/pool.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c > index 35bb51c31fff370f..1c7eab2cc0498003 100644 > --- a/kernel/dma/pool.c > +++ b/kernel/dma/pool.c > @@ -175,8 +175,8 @@ static int __init dma_atomic_pool_init(void) > * sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1. > */ > if (!atomic_pool_size) { > - atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) * > - SZ_128K; > + unsigned long gigs = totalram_pages() >> (30 - PAGE_SHIFT); > + atomic_pool_size = max(gigs, 1UL) * SZ_128K; > atomic_pool_size = min_t(size_t, atomic_pool_size, > 1 << (PAGE_SHIFT + MAX_ORDER-1)); > } Nit: although this probably is right, it seems even less readable than the broken version (where at least some at-a-glance 'dimensional analysis' flags up "(number of pages) >> PAGE_SHIFT" as rather suspicious). How about a something a little more self-explanatory, e.g.: unsigned long pages = totalram_pages() * SZ_128K / SZ_1GB; atomic_pool_size = min(pages, MAX_ORDER_NR_PAGES) << PAGE_SHIFT; atomic_pool_size = max_t(size_t, atomic_pool_size, SZ_128K); ? Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dma-pool: Fix too large DMA pools on medium systems 2020-06-08 12:03 ` Robin Murphy @ 2020-06-08 12:25 ` Geert Uytterhoeven 2020-06-08 12:53 ` Robin Murphy 0 siblings, 1 reply; 4+ messages in thread From: Geert Uytterhoeven @ 2020-06-08 12:25 UTC (permalink / raw) To: Robin Murphy Cc: Linux Kernel Mailing List, Linux IOMMU, David Rientjes, Christoph Hellwig Hi Robin, On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy <robin.murphy@arm.com> wrote: > On 2020-06-08 09:52, Geert Uytterhoeven wrote: > > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA > > memory pools are much larger than intended (e.g. 2 MiB instead of 128 > > KiB on a 256 MiB system). > > > > Fix this by correcting the calculation of the number of GiBs of RAM in > > the system. > > > > Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size with memory capacity") > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > > --- a/kernel/dma/pool.c > > +++ b/kernel/dma/pool.c > > @@ -175,8 +175,8 @@ static int __init dma_atomic_pool_init(void) > > * sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1. > > */ > > if (!atomic_pool_size) { > > - atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) * > > - SZ_128K; > > + unsigned long gigs = totalram_pages() >> (30 - PAGE_SHIFT); > > + atomic_pool_size = max(gigs, 1UL) * SZ_128K; > > atomic_pool_size = min_t(size_t, atomic_pool_size, > > 1 << (PAGE_SHIFT + MAX_ORDER-1)); > > } > > Nit: although this probably is right, it seems even less readable than ">> (x - PAGE_SHIFT)" is a commonly used construct in the kernel. > the broken version (where at least some at-a-glance 'dimensional > analysis' flags up "(number of pages) >> PAGE_SHIFT" as rather > suspicious). How about a something a little more self-explanatory, e.g.: > > unsigned long pages = totalram_pages() * SZ_128K / SZ_1GB; That multiplication will overflow on 32-bit systems (perhaps even on large 64-bit systems; any 47-bit addressing?). unsigned long pages = totalram_pages() / (SZ_1GB / SZ_128K); > atomic_pool_size = min(pages, MAX_ORDER_NR_PAGES) << PAGE_SHIFT; > atomic_pool_size = max_t(size_t, atomic_pool_size, SZ_128K); I agree this part is an improvement. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] dma-pool: Fix too large DMA pools on medium systems 2020-06-08 12:25 ` Geert Uytterhoeven @ 2020-06-08 12:53 ` Robin Murphy 0 siblings, 0 replies; 4+ messages in thread From: Robin Murphy @ 2020-06-08 12:53 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Linux IOMMU, Christoph Hellwig, Linux Kernel Mailing List, David Rientjes On 2020-06-08 13:25, Geert Uytterhoeven wrote: > Hi Robin, > > On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy <robin.murphy@arm.com> wrote: >> On 2020-06-08 09:52, Geert Uytterhoeven wrote: >>> On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA >>> memory pools are much larger than intended (e.g. 2 MiB instead of 128 >>> KiB on a 256 MiB system). >>> >>> Fix this by correcting the calculation of the number of GiBs of RAM in >>> the system. >>> >>> Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size with memory capacity") >>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > >>> --- a/kernel/dma/pool.c >>> +++ b/kernel/dma/pool.c >>> @@ -175,8 +175,8 @@ static int __init dma_atomic_pool_init(void) >>> * sizes to 128KB per 1GB of memory, min 128KB, max MAX_ORDER-1. >>> */ >>> if (!atomic_pool_size) { >>> - atomic_pool_size = max(totalram_pages() >> PAGE_SHIFT, 1UL) * >>> - SZ_128K; >>> + unsigned long gigs = totalram_pages() >> (30 - PAGE_SHIFT); >>> + atomic_pool_size = max(gigs, 1UL) * SZ_128K; >>> atomic_pool_size = min_t(size_t, atomic_pool_size, >>> 1 << (PAGE_SHIFT + MAX_ORDER-1)); >>> } >> >> Nit: although this probably is right, it seems even less readable than > > ">> (x - PAGE_SHIFT)" is a commonly used construct in the kernel. Sure, but when "x" is a magic number there's still extra cognitive load in determining whether it's the *right* magic number ;) Mostly, though, it was just the fact that an expression involving 5 different units (bytes, pages, "gigs", bits, and whatever MAX_ORDER is) is inherently more challenging to follow than the equivalent thing framed in fewer, especially when it can be reasonably done in just two (bytes and pages). Robin. >> the broken version (where at least some at-a-glance 'dimensional >> analysis' flags up "(number of pages) >> PAGE_SHIFT" as rather >> suspicious). How about a something a little more self-explanatory, e.g.: >> >> unsigned long pages = totalram_pages() * SZ_128K / SZ_1GB; > > That multiplication will overflow on 32-bit systems (perhaps even on > large 64-bit systems; any 47-bit addressing?). > > unsigned long pages = totalram_pages() / (SZ_1GB / SZ_128K); > >> atomic_pool_size = min(pages, MAX_ORDER_NR_PAGES) << PAGE_SHIFT; >> atomic_pool_size = max_t(size_t, atomic_pool_size, SZ_128K); > > I agree this part is an improvement. > > Gr{oetje,eeting}s, > > Geert > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-06-08 12:53 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-08 8:52 [PATCH] dma-pool: Fix too large DMA pools on medium systems Geert Uytterhoeven 2020-06-08 12:03 ` Robin Murphy 2020-06-08 12:25 ` Geert Uytterhoeven 2020-06-08 12:53 ` Robin Murphy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).