Re: [RFC] switch m68k to use the generic remapping DMA allocator
Hi Christoph, On Tue, Jun 25, 2019 at 9:35 AM Christoph Hellwig wrote: > On Tue, Jun 25, 2019 at 09:26:48AM +0200, Geert Uytterhoeven wrote: > > > > bloat-o-meter says: > > > > > > > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040) > > > > > > What do these values stand for? The code should grow a little as > > > we now need to include the the pool allocator for the above API > > > fix. > > > > Last 3 values are "bytes added/removed (net increase)". > > So this increases the static kernel size by ca. 4 KiB. > > That seems a lot for the little bit of pool code. Did m68k not Exactly, hence my original question... > build lib/genalloc.c by default before? Indeed, CONFIG_GENERIC_ALLOCATOR wasn't enabled before. --- .config.orig 2019-06-25 09:53:35.098691378 +0200 +++ .config 2019-06-25 09:59:23.914874446 +0200 @@ -2401,6 +2401,7 @@ CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_LZ4=y +CONFIG_GENERIC_ALLOCATOR=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m @@ -2409,6 +2410,10 @@ CONFIG_HAS_IOMEM=y CONFIG_HAS_DMA=y CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y +CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y +CONFIG_ARCH_HAS_DMA_MMAP_PGPROT=y +CONFIG_DMA_REMAP=y +CONFIG_DMA_DIRECT_REMAP=y # CONFIG_DMA_API_DEBUG is not set CONFIG_SGL_ALLOC=y CONFIG_DQL=y > Also I'd be curious what the first 4 values are. Reading scripts/bloat-o-meter in the kernel source tree tells me number of added/removed symbols (functions or variables), and number of grown/shrunk symbols. I run it regularly, to catch silly mistakes (cfr. my favorite one, fixed by commit 23c323af0375a7f6 ("SUNRPC: No, I did not intend to create a 256KiB hashtable")). Full output before/after for an atari_defconfig kernel (numbers are different, baseline has changed, too): $ bloat-o-meter vmlinux.orig vmlinux add/remove: 75/0 grow/shrink: 1/2 up/down: 4098/-28 (4070) Function old new delta gen_pool_alloc_algo_owner - 392+392 dma_atomic_pool_init - 360+360 gen_pool_best_fit - 248+248 dma_common_contiguous_remap- 238+238 gen_pool_destroy - 190+190 gen_pool_free_owner- 184+184 devm_gen_pool_create - 174+174 dma_alloc_from_pool- 152+152 bitmap_clear_ll- 138+138 arch_dma_free 12 136+124 dma_common_free_remap - 110+110 gen_pool_add_owner - 108+108 gen_pool_fixed_alloc - 100+100 dma_common_pages_remap - 92 +92 gen_pool_dma_alloc - 78 +78 arch_dma_prep_coherent - 76 +76 clear_bits_ll - 66 +66 dma_free_from_pool - 62 +62 set_bits_ll- 60 +60 devm_gen_pool_match- 56 +56 addr_in_gen_pool - 56 +56 gen_pool_create- 54 +54 gen_pool_virt_to_phys - 52 +52 gen_pool_first_fit_align - 52 +52 gen_pool_for_each_chunk- 42 +42 gen_pool_get - 40 +40 gen_pool_first_fit_order_align - 36 +36 gen_pool_set_algo - 34 +34 early_coherent_pool- 32 +32 __kstrtab_gen_pool_first_fit_order_align - 31 +31 gen_pool_size - 30 +30 arch_dma_mmap_pgprot - 28 +28 dma_in_atomic_pool - 26 +26 __kstrtab_gen_pool_alloc_algo_owner- 26 +26 __kstrtab_gen_pool_first_fit_align - 25 +25 gen_pool_avail - 24 +24 __kstrtab_gen_pool_for_each_chunk - 24 +24 __kstrtab_gen_pool_virt_to_phys- 22 +22 __kstrtab_gen_pool_fixed_alloc - 21 +21 __kstrtab_devm_gen_pool_create - 21 +21 arch_dma_coherent_to_pfn - 20 +20 __kstrtab_gen_pool_free_owner - 20 +20 __kstrtab_gen_pool_first_fit - 19 +19 __kstrtab_gen_pool_dma_alloc - 19 +19 __kstrtab_gen_pool_add_owner - 19 +19 __kstrtab_gen_pool_set_algo- 18 +18 __kstrtab_gen_pool_best_fit
Re: [RFC] switch m68k to use the generic remapping DMA allocator
On Tue, Jun 25, 2019 at 09:26:48AM +0200, Geert Uytterhoeven wrote: > > > bloat-o-meter says: > > > > > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040) > > > > What do these values stand for? The code should grow a little as > > we now need to include the the pool allocator for the above API > > fix. > > Last 3 values are "bytes added/removed (net increase)". > So this increases the static kernel size by ca. 4 KiB. That seems a lot for the little bit of pool code. Did m68k not build lib/genalloc.c by default before? Also I'd be curious what the first 4 values are.
Re: [RFC] switch m68k to use the generic remapping DMA allocator
Hi Christoph, On Tue, Jun 25, 2019 at 8:33 AM Christoph Hellwig wrote: > On Mon, Jun 17, 2019 at 08:53:55PM +0200, Geert Uytterhoeven wrote: > > On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote: > > > can you take a look at the (untested) patches below? They convert m68k > > > to use the generic remapping DMA allocator, which is also used by > > > arm64 and csky. > > > > Thanks. But what does this buy us? > > A common dma mapping code base with everyone, including supporting > DMA allocations from atomic context, which the documentation and > API assume are there, but which don't work on m68k. OK, thanks! > > bloat-o-meter says: > > > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040) > > What do these values stand for? The code should grow a little as > we now need to include the the pool allocator for the above API > fix. Last 3 values are "bytes added/removed (net increase)". So this increases the static kernel size by ca. 4 KiB. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [RFC] switch m68k to use the generic remapping DMA allocator
On Mon, Jun 24, 2019 at 09:16:30AM +0200, Geert Uytterhoeven wrote: > Doing > > - select DMA_DIRECT_REMAP if MMU && !COLDFIRE > + select DMA_DIRECT_REMAP if MMU && !COLDFIRE && !SUN3 > > in arch/m68k/Kconfig fixes the build. > > Alternatively, you could use: > > - select DMA_DIRECT_REMAP if MMU && !COLDFIRE > + select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE The latter might be a little cleaner.
Re: [RFC] switch m68k to use the generic remapping DMA allocator
On Mon, Jun 17, 2019 at 08:53:55PM +0200, Geert Uytterhoeven wrote: > Hi Christoph, > > On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote: > > can you take a look at the (untested) patches below? They convert m68k > > to use the generic remapping DMA allocator, which is also used by > > arm64 and csky. > > Thanks. But what does this buy us? A common dma mapping code base with everyone, including supporting DMA allocations from atomic context, which the documentation and API assume are there, but which don't work on m68k. > bloat-o-meter says: > > add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040) What do these values stand for? The code should grow a little as we now need to include the the pool allocator for the above API fix. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC] switch m68k to use the generic remapping DMA allocator
Hi Christoph, On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote: > can you take a look at the (untested) patches below? They convert m68k > to use the generic remapping DMA allocator, which is also used by > arm64 and csky. When building for Sun-3: kernel/dma/remap.o: In function `arch_dma_alloc': remap.c:(.text+0x316): undefined reference to `__dma_direct_alloc_pages' remap.c:(.text+0x32a): undefined reference to `arch_dma_prep_coherent' remap.c:(.text+0x34e): undefined reference to `arch_dma_mmap_pgprot' remap.c:(.text+0x378): undefined reference to `__dma_direct_free_pages' remap.c:(.text+0x3f4): undefined reference to `arch_dma_prep_coherent' remap.c:(.text+0x40a): undefined reference to `__dma_direct_alloc_pages' kernel/dma/remap.o: In function `arch_dma_free': remap.c:(.text+0x446): undefined reference to `__dma_direct_free_pages' remap.c:(.text+0x4a8): undefined reference to `__dma_direct_free_pages' kernel/dma/remap.o: In function `dma_atomic_pool_init': remap.c:(.init.text+0x66): undefined reference to `arch_dma_prep_coherent' Doing - select DMA_DIRECT_REMAP if MMU && !COLDFIRE + select DMA_DIRECT_REMAP if MMU && !COLDFIRE && !SUN3 in arch/m68k/Kconfig fixes the build. Alternatively, you could use: - select DMA_DIRECT_REMAP if MMU && !COLDFIRE + select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [RFC] switch m68k to use the generic remapping DMA allocator
Hi Christoph, On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote: > can you take a look at the (untested) patches below? They convert m68k > to use the generic remapping DMA allocator, which is also used by > arm64 and csky. Thanks. But what does this buy us? bloat-o-meter says: add/remove: 75/0 grow/shrink: 11/6 up/down: 4122/-82 (4040) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [RFC] switch m68k to use the generic remapping DMA allocator
Hi Christoph, On 14/6/19 8:21 pm, Christoph Hellwig wrote: Hi Geert and Greg, can you take a look at the (untested) patches below? They convert m68k to use the generic remapping DMA allocator, which is also used by arm64 and csky. No impact to ColdFire targets, so I'll have to defer to Geert for his thoughts on the legacy m68k impact. Regards Greg
[RFC] switch m68k to use the generic remapping DMA allocator
Hi Geert and Greg, can you take a look at the (untested) patches below? They convert m68k to use the generic remapping DMA allocator, which is also used by arm64 and csky. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu