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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
