Received: by 10.192.165.148 with SMTP id m20csp394713imm; Fri, 27 Apr 2018 00:20:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpkIQ7oIfpETsgnHtBmRvB8yuvkbY2dyIyjHVhN2EgUwtXVrIO/kLrEP5lQolULCYtZiE/G X-Received: by 2002:a17:902:f44:: with SMTP id 62-v6mr1269516ply.318.1524813605939; Fri, 27 Apr 2018 00:20:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524813605; cv=none; d=google.com; s=arc-20160816; b=pUNtAvVqnoFLwg9EANQYD5X5aa+k4hJqSVo27GP7Xp3X/6Xa/NwJ7u+/KJ8MuI0BFi Y3VTd33YSb39bdn9OXe7cWfRYA63H/SE25dZ4uikXuRg5+rRv1a5p9IzS+P1x7PG7yD8 lFXFQFOwtHJ1iJJ0fjH2H2Vv3+YgphP9CKj/FVaN5Nd8vv37KI8IMvfng5A40gYfnm2W kyCBdlGpxoBGQF9YL73Z0Z2qzix++3riI2CVA8K3PHeFYAfq+ZCspv10w7ct2i1CCwoI 44nJI4qCluzZ/nlIt+727sxXxVvVUSyKlhhFvabm0wMDK8ml27O/RQ9nGUicBgs8RwaH JQgA== 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=gWagjzS/i0x+aW37E0ZeaPMWVdAgvBnivpyt4JrmnqI=; b=N32pKlH4yvfYocNrBm+I1VC0V1awWJBOaPGQOhFRUFc+7pLPiVssFyB3XIy1ESvYgr JKglgR+rsaJLP0buJD85gIvyYezJodExUgOy2EzgebcClnNAD2BxQaMKG2B4Fw7cx/D/ Aao7IRDn4tXtcUBHYQFIxFMUsERCx1DNOOkgvIW2B7CXSsIqebyRkVgZHgOn1ur+7xwp IixZUNELGXXp+3EXq0rNBGJwW+Pg6vlelf4ymNqdnUBb0pY2Of7kdLr3YvEen1yfDaB4 VYa2hMRs7DaO40fZ6JSSLZSrDax5e3W5HSgu3JO42CaHWPTaMaT7EnvW5yk8Z+oqjWar rP+g== 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 32-v6si704532plc.252.2018.04.27.00.19.51; Fri, 27 Apr 2018 00:20:05 -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 S1757489AbeD0HSr (ORCPT + 99 others); Fri, 27 Apr 2018 03:18:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:33389 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753079AbeD0HSq (ORCPT ); Fri, 27 Apr 2018 03:18:46 -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 4E498AEBD; Fri, 27 Apr 2018 07:18:44 +0000 (UTC) Date: Fri, 27 Apr 2018 09:18:43 +0200 From: Michal Hocko To: Christoph Hellwig Cc: "Luis R. Rodriguez" , linux-mm@kvack.org, cl@linux.com, 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: <20180427071843.GB17484@dhcp22.suse.cz> References: <20180426215406.GB27853@wotan.suse.de> <20180427053556.GB11339@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180427053556.GB11339@infradead.org> 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 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) -- Michal Hocko SUSE Labs