Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp347185rwb; Thu, 11 Aug 2022 02:36:51 -0700 (PDT) X-Google-Smtp-Source: AA6agR594yrckpg8TqUMI72txLb4PAp9Z5upF3HU/40TkgOSyA3T+4CHkwU6s5u7KSp+Punh4VdK X-Received: by 2002:a05:6402:50cc:b0:43e:6860:58fc with SMTP id h12-20020a05640250cc00b0043e686058fcmr30201140edb.243.1660210611126; Thu, 11 Aug 2022 02:36:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660210611; cv=none; d=google.com; s=arc-20160816; b=iBXBKezHoiksi39mgfT2slEI+N0lbZpaj+2JgUhbpILElc/0SW7SyGzsoWIq7e/h/y m5Kp2xuEwE09fIcZ01MK4NnoX304+4sLdYjAqHqKLmBo67kwa2nA9uQ4kQjHBypXYhx2 UZJsv5jGa4OPB1YNoxoAMFCCcYyMtCT3PUSPrVmF1CoUcaiYOf1wLu/zAwX9ci1Qimtq jS+Naki5ij8D5pncYSfxd4xox9Mk7Le+B++7GCON4lFERpCU5IsIwMU6zf31YBWsKbsU mZQaBdvFg8sWsnNqfHpuIAQLRMqz/brK7zgsOHb688uX3KksTpQ6lYVlx6Lhzw25x+yw cGmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BXWAGelHI6Qf6b5shKf8Bk4XHQmDrurWKAtmRuaA1lk=; b=TMui+icPNQPqYNBXaEagJBi6LO6HjXM1PE5FqL2DoK6L/6AJT1YguyaTI6oSqoe/3u 4VStMZMffVjXISm7tt6OCfdBVUHCbQCNmuOiltM6bowOml9PwL+segxayLHF8gn4St4Y O2u65zIwMWvG69UWInFPbWQiPUuhro7Dxyba1Irwlh+VlCYU4edPMBd0ytRbDvPpWxsk M/TQisjPwTW3COtjOrWx6iYGkIWGuje4j7VNti8cK9h4IbCiESxr/I23LHmNYFP0TcJd mzt58+bhG3OR4aeu0fQyPYoFo2y/qElEXNT9JkODpFJslNa1w4S60LEO5TQWuF3HhrXM n7ag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=CFz7NxCY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m15-20020a056402050f00b0043d14d03dd9si12114341edv.496.2022.08.11.02.36.24; Thu, 11 Aug 2022 02:36:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=CFz7NxCY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234584AbiHKImZ (ORCPT + 99 others); Thu, 11 Aug 2022 04:42:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234376AbiHKImX (ORCPT ); Thu, 11 Aug 2022 04:42:23 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90F748E0D1 for ; Thu, 11 Aug 2022 01:42:22 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4D90E5C43C; Thu, 11 Aug 2022 08:42:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1660207341; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BXWAGelHI6Qf6b5shKf8Bk4XHQmDrurWKAtmRuaA1lk=; b=CFz7NxCY7AZFWjv40Es5ZAs6bhLkTtcLM1wVqjiLOYeAYKaPu/Kq0dNPbDmRfxNMFbMsX2 kSSIu34EHghF+0je4TlVdzCABrL1AQp7BeFRq3MwYIjUFtYecaMbwYI9i/ibcSHhQOYsKu P8pkDizvAFUylntNXVQ2NJh1itONNi0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2B57213A9B; Thu, 11 Aug 2022 08:42:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id zPNWCO3A9GJYWQAAMHmgww (envelope-from ); Thu, 11 Aug 2022 08:42:21 +0000 Date: Thu, 11 Aug 2022 10:42:20 +0200 From: Michal Hocko To: Christoph Hellwig Cc: Baoquan He , Andrew Morton , John Donnelly , David Hildenbrand , linux-mm@kvack.org, LKML Subject: Re: [PATCH] dma/pool: do not complain if DMA pool is not allocated Message-ID: References: <20220325164856.GA16800@lst.de> <20220811074946.GB14956@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220811074946.GB14956@lst.de> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 11-08-22 09:49:46, Christoph Hellwig wrote: > On Thu, Aug 04, 2022 at 07:01:28PM +0800, Baoquan He wrote: > > After attempts, I realize it's time to let one zone DMA or DMA32 cover > > the whole low 4G memory on x86_64. That's the real fix. The tiny 16M DMA > > on 64bit system is root cause. > > We can't for two reasons: > > - people still use ISA cards on x86, including the industrial PC104 > version, and we still have drivers that rely on it > - we still have PCI and PCIe devices with small than 26, 28, 30 and 31 > bit addressing limitations > > We could try to get the 24-bit DMA entirely out of the zone allocator > and only fill a genpool at bootmem time. But that requires fixing up > all the direct users of page and slab allocations on it first (of > which 90+% look bogus, with the s390 drivers being the obvious > exception). Completely agreed! > Or we could make 'low' memory a special ZONE_MOVABLE and have an > allocator that can search by physical address an replace ZONE_DMA > and ZONE_DMA32 with that. Which sounds like a nice idea to me, but > is pretty invasive. Yes. -- Michal Hocko SUSE Labs