From: Catalin Marinas <catalin.marinas@arm.com>
To: peng.fan@nxp.com
Cc: will@kernel.org, linux-kernel@vger.kernel.org,
nsaenzjulienne@suse.de, linux-imx@nxp.com,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: mm: make CONFIG_ZONE_DMA configurable without EXPERT
Date: Tue, 24 Mar 2020 17:41:35 +0000 [thread overview]
Message-ID: <20200324174134.GH3901@mbp> (raw)
In-Reply-To: <1583844526-24229-1-git-send-email-peng.fan@nxp.com>
On Tue, Mar 10, 2020 at 08:48:46PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
> enables both ZONE_DMA and ZONE_DMA32. The lower 1GB memory
> will be occupied by ZONE_DMA, this will cause CMA allocation
> fail on some platforms, because CMA area could not across
> different type of memory zones.
>
> Make CONFIG_ZONE_DMA configurable without EXPERT option
> could let people build non debug kernel image with
> CONFIG_ZONE_DMA disabled.
While I see why you need to toggle this feature, I'd rather try to
figure out whether there is a better solution that does not break the
single kernel image aim (i.e. the same config works for all supported
SoCs).
When we decided to go ahead with a static 1GB ZONE_DMA for Raspberry Pi
4, we thought that other platforms would be fine, ZONE_DMA32 allocations
fall back to ZONE_DMA. We missed the large CMA case.
I see a few potential options:
a) Ensure the CMA is contained within a single zone. How large is it in
your case? Is it allocated by the kernel dynamically or a fixed start
set by the boot loader?
b) Change the CMA allocator to allow spanning multiple zones (last time
I looked it wasn't trivial since it relied on some per-zone lock).
c) Make ZONE_DMA dynamic on arm64 and only enable it if RPi4.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: peng.fan@nxp.com
Cc: will@kernel.org, nsaenzjulienne@suse.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] arm64: mm: make CONFIG_ZONE_DMA configurable without EXPERT
Date: Tue, 24 Mar 2020 17:41:35 +0000 [thread overview]
Message-ID: <20200324174134.GH3901@mbp> (raw)
In-Reply-To: <1583844526-24229-1-git-send-email-peng.fan@nxp.com>
On Tue, Mar 10, 2020 at 08:48:46PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
> enables both ZONE_DMA and ZONE_DMA32. The lower 1GB memory
> will be occupied by ZONE_DMA, this will cause CMA allocation
> fail on some platforms, because CMA area could not across
> different type of memory zones.
>
> Make CONFIG_ZONE_DMA configurable without EXPERT option
> could let people build non debug kernel image with
> CONFIG_ZONE_DMA disabled.
While I see why you need to toggle this feature, I'd rather try to
figure out whether there is a better solution that does not break the
single kernel image aim (i.e. the same config works for all supported
SoCs).
When we decided to go ahead with a static 1GB ZONE_DMA for Raspberry Pi
4, we thought that other platforms would be fine, ZONE_DMA32 allocations
fall back to ZONE_DMA. We missed the large CMA case.
I see a few potential options:
a) Ensure the CMA is contained within a single zone. How large is it in
your case? Is it allocated by the kernel dynamically or a fixed start
set by the boot loader?
b) Change the CMA allocator to allow spanning multiple zones (last time
I looked it wasn't trivial since it relied on some per-zone lock).
c) Make ZONE_DMA dynamic on arm64 and only enable it if RPi4.
--
Catalin
next prev parent reply other threads:[~2020-03-24 17:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 12:48 [PATCH] arm64: mm: make CONFIG_ZONE_DMA configurable without EXPERT peng.fan
2020-03-10 12:48 ` peng.fan
2020-03-23 1:30 ` Peng Fan
2020-03-23 1:30 ` Peng Fan
2020-03-24 17:41 ` Catalin Marinas [this message]
2020-03-24 17:41 ` Catalin Marinas
2020-03-25 0:34 ` Peng Fan
2020-03-25 0:34 ` Peng Fan
2020-03-25 10:16 ` Catalin Marinas
2020-03-25 10:16 ` Catalin Marinas
2020-03-25 12:30 ` Peng Fan
2020-03-25 12:30 ` Peng Fan
2020-03-27 11:17 ` Nicolas Saenz Julienne
2020-03-27 11:17 ` Nicolas Saenz Julienne
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=20200324174134.GH3901@mbp \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nsaenzjulienne@suse.de \
--cc=peng.fan@nxp.com \
--cc=robin.murphy@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.