All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Peng Fan <peng.fan@nxp.com>
Cc: "will@kernel.org" <will@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"nsaenzjulienne@suse.de" <nsaenzjulienne@suse.de>,
	dl-linux-imx <linux-imx@nxp.com>,
	Robin Murphy <robin.murphy@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: mm: make CONFIG_ZONE_DMA configurable without EXPERT
Date: Wed, 25 Mar 2020 10:16:52 +0000	[thread overview]
Message-ID: <20200325101652.GJ3901@mbp> (raw)
In-Reply-To: <AM0PR04MB44819E95EB1FABF09DEE682788CE0@AM0PR04MB4481.eurprd04.prod.outlook.com>

On Wed, Mar 25, 2020 at 12:34:15AM +0000, Peng Fan wrote:
> > 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. 
> 
> This will break legacy dts with new version kernel.
> 
> > How large is it in your case? 
> 
> It is 1GB
> 
> > Is it allocated by the kernel dynamically or a fixed start set by
> > the boot loader?
> 
> We use alloc-ranges and size in kernel dts.
> 
> But there is only 2GB DRAM in the board.

So I guess without changing the dts, option (a) doesn't really work.

> > 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.
> 
> Option c seems a bit easier to me :)
> 
> I will try to explore both, but if you have time to help, that would be
> appreciated.

I don't have time but option (c) was already discussed and there are
patches from Nicolas on the list:

https://lore.kernel.org/linux-arm-kernel/20190820145821.27214-5-nsaenzjulienne@suse.de/

The above series was checking whether the platform is RPi4 and limiting
the ZONE_DMA size to 1GB (otherwise 4GB with ZONE_DMA32 empty). We ended
up with a static 1GB for ZONE_DMA but we missed the fact that it may
break existing platforms.

So I don't think it would be too hard to revive the above series (most
of it was already merged).

-- 
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 <peng.fan@nxp.com>
Cc: "will@kernel.org" <will@kernel.org>,
	"nsaenzjulienne@suse.de" <nsaenzjulienne@suse.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] arm64: mm: make CONFIG_ZONE_DMA configurable without EXPERT
Date: Wed, 25 Mar 2020 10:16:52 +0000	[thread overview]
Message-ID: <20200325101652.GJ3901@mbp> (raw)
In-Reply-To: <AM0PR04MB44819E95EB1FABF09DEE682788CE0@AM0PR04MB4481.eurprd04.prod.outlook.com>

On Wed, Mar 25, 2020 at 12:34:15AM +0000, Peng Fan wrote:
> > 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. 
> 
> This will break legacy dts with new version kernel.
> 
> > How large is it in your case? 
> 
> It is 1GB
> 
> > Is it allocated by the kernel dynamically or a fixed start set by
> > the boot loader?
> 
> We use alloc-ranges and size in kernel dts.
> 
> But there is only 2GB DRAM in the board.

So I guess without changing the dts, option (a) doesn't really work.

> > 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.
> 
> Option c seems a bit easier to me :)
> 
> I will try to explore both, but if you have time to help, that would be
> appreciated.

I don't have time but option (c) was already discussed and there are
patches from Nicolas on the list:

https://lore.kernel.org/linux-arm-kernel/20190820145821.27214-5-nsaenzjulienne@suse.de/

The above series was checking whether the platform is RPi4 and limiting
the ZONE_DMA size to 1GB (otherwise 4GB with ZONE_DMA32 empty). We ended
up with a static 1GB for ZONE_DMA but we missed the fact that it may
break existing platforms.

So I don't think it would be too hard to revive the above series (most
of it was already merged).

-- 
Catalin

  reply	other threads:[~2020-03-25 10:17 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
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 [this message]
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=20200325101652.GJ3901@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.