Received: by 10.192.165.148 with SMTP id m20csp924479imm; Fri, 27 Apr 2018 09:39:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZok+ZIn+n6OB7aH09fwp6gKKYpPxXGC3rNSlQE2rkErLItdAz8YV9eX19ZR1jEDZ5Ze/pQP X-Received: by 10.98.26.78 with SMTP id a75mr2818670pfa.84.1524847144327; Fri, 27 Apr 2018 09:39:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524847144; cv=none; d=google.com; s=arc-20160816; b=wyrPGCKye1A0hnJZa4vJC4xsPv67ToE6t4u1CqhQX+dGeDKCE9Bvzn2NSLkJQjRwqu e0Fde2FGlZJO3/VKXDOgErpz7eSFklFdKaI2mmd+Kn5U/eFg5ri3Yxe/e1xj/GX3AnFJ qyxlVoFw2mONZFH/CNZYuypstRq9LBXFO7+eKkOWasFNmIsXsoIeMjxXYwevcP6pDpRX FeVxjMkw+KRExG0BbgOtmprxv+BcTf+VScqzg9UQLSfUoAoINW27qnjpDqMqMDc0c3PK V1n8ZNNk9z70Wntj33F32/ChU7AFvpezeGTlRqhinQAWoXPAkmhLoohvVrw3BKhgzanq nY8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=72RTL2cNrAtjh0SWNfoXUlTWn6Lm978B+usEKrbLqww=; b=ooNDBvXmpo17ha8bDqLhv8kDZYZGcX6nl6uyWezBI2g5sMsF/M1LiGOphVRcn8qTQZ l2eOkMlb9NKEhcw07KYerW77V+6QU52njv5AELr1EF6/HyF5N0X4EUNW2jHb6V/FT3yw UCuYXFiEuHE5tCDNw/U67OU6mDOhu8+xDyXk26R35G0Ueov4dxeQFuWUzWK6OarbOglu hhiymjEaUO03ClI2bU63gv1bu/2WLQuu6pbjLoo1PbXXKt3t9ICUq1NpeF/5BgiVSASE YcaU60v+hFg6VcGdG9lQ6CkBbGv6zSxNx7n8OGByiJFl4weM6qv55a7LTZHAW3nvoLCM Ta6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r10-v6si1612217plo.344.2018.04.27.09.38.50; Fri, 27 Apr 2018 09:39:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758824AbeD0Qhq (ORCPT + 99 others); Fri, 27 Apr 2018 12:37:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:49119 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757716AbeD0Qho (ORCPT ); Fri, 27 Apr 2018 12:37:44 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E0919AC07; Fri, 27 Apr 2018 16:37:42 +0000 (UTC) Date: Fri, 27 Apr 2018 18:37:40 +0200 From: Michal Hocko To: Christopher Lameter Cc: Christoph Hellwig , "Luis R. Rodriguez" , linux-mm@kvack.org, Jan Kara , matthew@wil.cx, x86@kernel.org, luto@amacapital.net, martin.petersen@oracle.com, jthumshirn@suse.de, broonie@kernel.org, linux-spi@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, "lsf-pc@lists.linux-foundation.org" Subject: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love Message-ID: <20180427163740.GI17484@dhcp22.suse.cz> References: <20180426215406.GB27853@wotan.suse.de> <20180427053556.GB11339@infradead.org> <20180427071843.GB17484@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 27-04-18 11:07:07, Cristopher Lameter wrote: > On Fri, 27 Apr 2018, Michal Hocko wrote: > > > On Thu 26-04-18 22:35:56, Christoph Hellwig wrote: > > > On Thu, Apr 26, 2018 at 09:54:06PM +0000, Luis R. Rodriguez wrote: > > > > In practice if you don't have a floppy device on x86, you don't need ZONE_DMA, > > > > > > I call BS on that, and you actually explain later why it it BS due > > > to some drivers using it more explicitly. But even more importantly > > > we have plenty driver using it through dma_alloc_* and a small DMA > > > mask, and they are in use - we actually had a 4.16 regression due to > > > them. > > > > Well, but do we need a zone for that purpose? The idea was to actually > > replace the zone by a CMA pool (at least on x86). With the current > > implementation of the CMA we would move the range [0-16M] pfn range into > > zone_movable so it can be used and we would get rid of all of the > > overhead each zone brings (a bit in page flags, kmalloc caches and who > > knows what else) > > Well it looks like what we are using it for is to force allocation from > low physical memory if we fail to obtain proper memory through a normal > channel. The use of ZONE_DMA is only there for emergency purposes. > I think we could subsitute ZONE_DMA32 on x87 without a problem. > > Which means that ZONE_DMA has no purpose anymore. We still need to make sure the low 16MB is available on request. And that is what CMA can help with. We do not really seem to need the whole zone infreastructure for that. > Can we make ZONE_DMA on x86 refer to the low 32 bit physical addresses > instead and remove ZONE_DMA32? Why that would be an advantage? If anything I would rename ZONE_DMA32 to ZONE_ADDR32 or something like that. > That would actually improve the fallback because you have more memory for > the old devices. I do not really understand how is that related to removal ZONE_DMA. We are really talking about the lowest 16MB... -- Michal Hocko SUSE Labs