[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230127063555.GA3300@lst.de>
Date: Fri, 27 Jan 2023 07:35:55 +0100
From: Christoph Hellwig <hch@....de>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Georgi Djakov <quic_c_gdjako@...cinc.com>, catalin.marinas@....com,
will@...nel.org, dave.hansen@...ux.intel.com, luto@...nel.org,
peterz@...radead.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, hpa@...or.com, hch@....de, m.szyprowski@...sung.com,
robin.murphy@....com, linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
djakov@...nel.org
Subject: Re: [RFC] mm: Allow ZONE_DMA32 to be disabled via kernel command
line
On Thu, Jan 26, 2023 at 10:51:17AM -0800, Dave Hansen wrote:
>
> Also, what are the practical implications here? There are obviously an
> ever decreasing number of 32-bit DMA devices out there. Somebody that
> has one and uses this option might be sad because now they're stuck
> using ZONE_DMA which is quite tiny.
>
> What other ZONE_DMA32 users are left? Will anyone else care? There is
> some DMA32 slab and vmalloc() functionality remaining. Is it impacted?
DMA32 never supported lab. But < 64-bit DMA device are unfortunately
still not uncommon, and configuring out ZONE_DMA32 breaks them pretty
badly as we guarantee that a DMA mask of 32-bit always works.
So I'm not only very much against this patch, but also the currently
existing way to configure out ZONE_DMA32 on arm64, which needs to
go away.
If people want ZONE_DMA32 to go away we need something to replace
it first, like a large enough CMA region in the 32-bit addressable
range.
Powered by blists - more mailing lists