From: Christoph Hellwig <hch@lst.de>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Georgi Djakov <quic_c_gdjako@quicinc.com>,
catalin.marinas@arm.com, will@kernel.org,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, hch@lst.de,
m.szyprowski@samsung.com, robin.murphy@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, djakov@kernel.org
Subject: Re: [RFC] mm: Allow ZONE_DMA32 to be disabled via kernel command line
Date: Fri, 27 Jan 2023 07:35:55 +0100 [thread overview]
Message-ID: <20230127063555.GA3300@lst.de> (raw)
In-Reply-To: <dca84e05-e376-c593-74fa-37c58f30767a@intel.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Georgi Djakov <quic_c_gdjako@quicinc.com>,
catalin.marinas@arm.com, will@kernel.org,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, hch@lst.de,
m.szyprowski@samsung.com, robin.murphy@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, djakov@kernel.org
Subject: Re: [RFC] mm: Allow ZONE_DMA32 to be disabled via kernel command line
Date: Fri, 27 Jan 2023 07:35:55 +0100 [thread overview]
Message-ID: <20230127063555.GA3300@lst.de> (raw)
In-Reply-To: <dca84e05-e376-c593-74fa-37c58f30767a@intel.com>
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-27 6:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 16:43 [RFC] mm: Allow ZONE_DMA32 to be disabled via kernel command line Georgi Djakov
2023-01-26 16:43 ` Georgi Djakov
2023-01-26 18:51 ` Dave Hansen
2023-01-26 18:51 ` Dave Hansen
2023-01-26 22:56 ` Georgi Djakov
2023-01-26 22:56 ` Georgi Djakov
2023-01-27 0:57 ` Randy Dunlap
2023-01-27 0:57 ` Randy Dunlap
2023-01-27 6:35 ` Christoph Hellwig [this message]
2023-01-27 6:35 ` Christoph Hellwig
2023-01-27 6:52 ` H. Peter Anvin
2023-01-27 6:52 ` H. Peter Anvin
2023-01-27 7:07 ` Christoph Hellwig
2023-01-27 7:07 ` Christoph Hellwig
2023-01-26 19:15 ` Robin Murphy
2023-01-26 19:15 ` Robin Murphy
2023-01-27 2:20 ` Chris Goldsworthy
2023-01-27 2:20 ` Chris Goldsworthy
2023-01-27 8:55 ` Hillf Danton
2023-01-27 8:55 ` Hillf Danton
2023-02-01 4:09 ` Chris Goldsworthy
2023-02-01 4:09 ` Chris Goldsworthy
2023-01-30 5:26 ` kernel test robot
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=20230127063555.GA3300@lst.de \
--to=hch@lst.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=djakov@kernel.org \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quic_c_gdjako@quicinc.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--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.