From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751243AbdEBNno (ORCPT ); Tue, 2 May 2017 09:43:44 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:25483 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750886AbdEBNnk (ORCPT ); Tue, 2 May 2017 09:43:40 -0400 Subject: Re: [PATCH v7 0/7] Introduce ZONE_CMA To: Michal Hocko , Vlastimil Babka References: <1491880640-9944-1-git-send-email-iamjoonsoo.kim@lge.com> <20170411181519.GC21171@dhcp22.suse.cz> <20170412013503.GA8448@js1304-desktop> <20170413115615.GB11795@dhcp22.suse.cz> <20170417020210.GA1351@js1304-desktop> <20170424130936.GB1746@dhcp22.suse.cz> <20170425034255.GB32583@js1304-desktop> <20170427150636.GM4706@dhcp22.suse.cz> <32ac1107-14a3-fdff-ad48-0e246fec704f@suse.cz> <20170502130326.GJ14593@dhcp22.suse.cz> CC: Joonsoo Kim , Andrew Morton , Rik van Riel , Johannes Weiner , , Laura Abbott , "Minchan Kim" , Marek Szyprowski , "Michal Nazarewicz" , "Aneesh Kumar K . V" , Russell King , "Will Deacon" , , , From: Igor Stoppa Message-ID: <2cd6a2c5-6e78-1d34-69b5-97a7de740b06@huawei.com> Date: Tue, 2 May 2017 16:41:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502130326.GJ14593@dhcp22.suse.cz> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.59088CEA.0149,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bfbc7c9004928f8c50d33ef113fd1285 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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