Linux-RISC-V Archive mirror
 help / color / mirror / Atom feed
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

      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).