Messages in this thread | | | Subject | Re: [PATCH v7 0/7] Introduce ZONE_CMA | From | Igor Stoppa <> | Date | Tue, 2 May 2017 16:41:55 +0300 |
| |
On 02/05/17 16:03, Michal Hocko wrote:
> I can imagine that we could make ZONE_CMA configurable in a way that > only very well defined use cases would be supported so that we can save > page flags space. But this alone sounds like a maintainability nightmare > to me. Especially when I consider ZONE_DMA situation. There is simply > not an easy way to find out whether my HW really needs DMA zone or > not. Most probably not but it still is configured and hidden behind > config ZONE_DMA > bool "DMA memory allocation support" if EXPERT > default y > help > DMA memory allocation support allows devices with less than 32-bit > addressing to allocate within the first 16MB of address space. > Disable if no such devices will be used. > > If unsure, say Y. > > Are we really ready to add another thing like that? How are distribution > kernels going to handle that?
In practice there are 2 quite opposite scenarios:
- distros that try to cater to (almost) everyone and are constrained in what they can leave out
- ad-hoc builds (like Android, but also IoT) where the HW is *very* well known upfront, because it's probably even impossible to make any change that doesn't involved a rework station.
So maybe the answer is to not have only EXPERT, but rather DISTRO/CUSTOM with the implications these can bring.
A generic build would assume to be a DISTRO type, but something else, of more embedded persuasion, could do otherwise.
ZONE_DMA / ZONE_DMA32 actually seem to be perfect candidates for being replaced by something else, when unused, as I proposed on Friday:
http://marc.info/?l=linux-mm&m=149337033630993&w=2
It might still be that only some cases would be upstreamable, even after these changes.
But at least some of those might be useful also for non-Android/ non-IoT scenarios.
--- igor
| |