All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Ross Burton <ross.burton@arm.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH] arm64: swiotlb: Reduce the default size if no ZONE_DMA bouncing needed
Date: Fri, 6 Oct 2023 17:45:51 +0100	[thread overview]
Message-ID: <ZSA5vwYtLjh3bpss@arm.com> (raw)
In-Reply-To: <d8391344-53f5-4ea4-8e04-d4fd33f72be9@arm.com>

On Fri, Oct 06, 2023 at 05:25:03PM +0100, Robin Murphy wrote:
> On 2023-10-06 16:32, Catalin Marinas wrote:
> > With CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC enabled, the arm64 kernel still
> > allocates the default SWIOTLB buffer (64MB) even if ZONE_DMA is disabled
> > or all the RAM fits into this zone. However, this potentially wastes a
> > non-negligible amount of memory on platforms with little RAM.
> > 
> > Reduce the SWIOTLB size to 1MB per 1GB of RAM if only needed for
> > kmalloc() buffer bouncing.
> > 
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Suggested-by: Ross Burton <ross.burton@arm.com>
> > Cc: Ross Burton <ross.burton@arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> >   arch/arm64/mm/init.c | 10 +++++++++-
> >   1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 8a0f8604348b..54ee1a4868c2 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -493,8 +493,16 @@ void __init mem_init(void)
> >   {
> >   	bool swiotlb = max_pfn > PFN_DOWN(arm64_dma_phys_limit);
> > -	if (IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC))
> > +	if (IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && !swiotlb) {
> > +		/*
> > +		 * If no bouncing needed for ZONE_DMA, reduce the swiotlb
> > +		 * buffer for kmalloc() bouncing to 1MB per 1GB of RAM.
> > +		 */
> > +		unsigned long size =
> > +			ALIGN(memblock_phys_mem_size(), SZ_1G) >> 10;
> 
> Hmm, I wondered if DIV_ROUND_UP(memblock_phys_mem_size(), 1024) might be any
> easier, but by the time I've typed it out it's still just as long :)

It's not the same result as it's rounded up to the nearest KB rather
than MB. But this may work as well. I just made up this number really.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-10-06 16:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-06 15:32 [PATCH] arm64: swiotlb: Reduce the default size if no ZONE_DMA bouncing needed Catalin Marinas
2023-10-06 16:25 ` Robin Murphy
2023-10-06 16:45   ` Catalin Marinas [this message]
2023-10-13 18:45 ` Catalin Marinas

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=ZSA5vwYtLjh3bpss@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=ross.burton@arm.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.