[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4027201b6128b3f2b0ab941dc473ab143da64be2.camel@suse.de>
Date: Thu, 01 Aug 2019 18:40:50 +0200
From: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To: Robin Murphy <robin.murphy@....com>,
Catalin Marinas <catalin.marinas@....com>
Cc: phill@...pberryi.org, devicetree@...r.kernel.org,
f.fainelli@...il.com, linux-mm@...ck.org, marc.zyngier@....com,
Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org,
eric@...olt.net, iommu@...ts.linux-foundation.org,
robh+dt@...nel.org, linux-rpi-kernel@...ts.infradead.org,
mbrugger@...e.com, akpm@...ux-foundation.org,
m.szyprowski@...sung.com, frowand.list@...il.com, hch@....de,
linux-arm-kernel@...ts.infradead.org, wahrenst@....net
Subject: Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited
devices
On Thu, 2019-08-01 at 17:07 +0100, Robin Murphy wrote:
> On 2019-08-01 4:44 pm, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote:
> > > On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote:
> > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > index 1c4ffabbe1cb..f5279ef85756 100644
> > > > --- a/arch/arm64/mm/init.c
> > > > +++ b/arch/arm64/mm/init.c
> > > > @@ -50,6 +50,13 @@
> > > > s64 memstart_addr __ro_after_init = -1;
> > > > EXPORT_SYMBOL(memstart_addr);
> > > >
> > > > +/*
> > > > + * We might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed
> > > > if
> > > > there
> > > > + * are periferals unable to address the first naturally aligned 4GB of
> > > > ram.
> > > > + * ZONE_DMA32 will be expanded to cover the rest of that memory. If
> > > > such
> > > > + * limitations doesn't exist only ZONE_DMA32 is created.
> > > > + */
> > >
> > > Shouldn't we instead only create ZONE_DMA to cover the whole 32-bit
> > > range and leave ZONE_DMA32 empty? Can__GFP_DMA allocations fall back
> > > onto ZONE_DMA32?
> >
> > Hi Catalin, thanks for the review.
> >
> > You're right, the GFP_DMA page allocation will fail with a nasty dmesg error
> > if
> > ZONE_DMA is configured but empty. Unsurprisingly the opposite situation is
> > fine
> > (GFP_DMA32 with an empty ZONE_DMA32).
>
> Was that tested on something other than RPi4 with more than 4GB of RAM?
> (i.e. with a non-empty ZONE_NORMAL either way)
No, all I did is play around with RPi4's memory size (1 GB vs 4 GB).
I'll see If I can get access to a dts based board with more than 4 GB, If not
I'll try to fake it. It's not ideal but I can set the limit on 3 GB and have
the 3 areas created (with and witouth an empty ZONE_DMA32).
On top of that, now that you ask, I realise I neglected all the ACPI based
servers. I have access to some so I'll make sure I test everything on them too
for the next series.
Regards,
Nicolas
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists