From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
Alexandre Ghiti <alexghiti@rivosinc.com>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 RESEND] riscv: mm: still create swiotlb buffer for kmalloc() bouncing if required
Date: Tue, 7 May 2024 17:08:15 +0200 [thread overview]
Message-ID: <CAMuHMdUckNuraENvsiQ_QHmzNQeT_-9_jZvKZr5LuiFEJVFnmQ@mail.gmail.com> (raw)
In-Reply-To: <20240325110036.1564-1-jszhang@kernel.org>
Hi Jisheng,
On Mon, Mar 25, 2024 at 12:15 PM Jisheng Zhang <jszhang@kernel.org> wrote:
> After commit f51f7a0fc2f4 ("riscv: enable DMA_BOUNCE_UNALIGNED_KMALLOC
> for !dma_coherent"), for non-coherent platforms with less than 4GB
> memory, we rely on users to pass "swiotlb=mmnn,force" kernel parameters
> to enable DMA bouncing for unaligned kmalloc() buffers. Now let's go
> further: If no bouncing needed for ZONE_DMA, let kernel automatically
> allocate 1MB swiotlb buffer per 1GB of RAM for kmalloc() bouncing on
> non-coherent platforms, so that no need to pass "swiotlb=mmnn,force"
> any more.
>
> The math of "1MB swiotlb buffer per 1GB of RAM for kmalloc() bouncing"
> is taken from arm64. Users can still force smaller swiotlb buffer by
> passing "swiotlb=mmnn".
>
> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Thanks for your patch, which is now commit fc7a50eed9860d4b ("riscv:
mm: still create swiotlb buffer for kmalloc() bouncing if required")
in riscv/for-next (next-20240429 and later).
On RZ/Five, which has 1 GiB of RAM, i.e. a bit less for free use:
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
Built 1 zonelists, mobility grouping on. Total pages: 225792
mem auto-init: stack:off, heap alloc:off, heap free:off
+software IO TLB: SWIOTLB bounce buffer size adjusted to 0MB
^^^
+software IO TLB: area num 1.
+software IO TLB: mapped [mem 0x000000007ef56000-0x000000007f056000] (1MB)
^^^
Virtual kernel memory layout:
I was a bit intrigued by the "0MB". However, that seems to be correct:
mem_init: memblock_phys_mem_size() = 939524096
mem_init: size = 917504
mem_init: swiotlb_size_or_default() = 67108864
and it must be rounded up to 1 MB later.
Apparently arm64 has the same discrepancy, which I never really noticed
before (and I have no arm64 platforms with 1 GiB RAM or less):
mem_init: memblock_phys_mem_size() = 2013265920
mem_init: size = 1966080
mem_init: swiotlb_size_or_default() = 67108864
software IO TLB: SWIOTLB bounce buffer size adjusted to 1MB
^^^
software IO TLB: area num 2.
software IO TLB: mapped [mem 0x00000000b9400000-0x00000000b9600000] (2MB)
^^^
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -161,11 +161,25 @@ static void print_vm_layout(void) { }
>
> void __init mem_init(void)
> {
> + bool swiotlb = max_pfn > PFN_DOWN(dma32_phys_limit);
> #ifdef CONFIG_FLATMEM
> BUG_ON(!mem_map);
> #endif /* CONFIG_FLATMEM */
>
> - swiotlb_init(max_pfn > PFN_DOWN(dma32_phys_limit), SWIOTLB_VERBOSE);
> + if (IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && !swiotlb &&
> + dma_cache_alignment != 1) {
> + /*
> + * If no bouncing needed for ZONE_DMA, allocate 1MB swiotlb
> + * buffer per 1GB of RAM for kmalloc() bouncing on
> + * non-coherent platforms.
> + */
> + unsigned long size =
> + DIV_ROUND_UP(memblock_phys_mem_size(), 1024);
> + swiotlb_adjust_size(min(swiotlb_size_or_default(), size));
> + swiotlb = true;
> + }
> +
> + swiotlb_init(swiotlb, SWIOTLB_VERBOSE);
> memblock_free_all();
>
> print_vm_layout();
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
prev parent reply other threads:[~2024-05-07 15:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 11:00 [PATCH v3 RESEND] riscv: mm: still create swiotlb buffer for kmalloc() bouncing if required Jisheng Zhang
2024-04-28 22:00 ` patchwork-bot+linux-riscv
2024-05-07 15:08 ` Geert Uytterhoeven [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdUckNuraENvsiQ_QHmzNQeT_-9_jZvKZr5LuiFEJVFnmQ@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=jszhang@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).