From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE0A7C433EF for ; Thu, 9 Dec 2021 13:00:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E3656B0071; Thu, 9 Dec 2021 08:00:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 26BAC6B0073; Thu, 9 Dec 2021 08:00:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10E8C6B0074; Thu, 9 Dec 2021 08:00:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id F0F126B0071 for ; Thu, 9 Dec 2021 08:00:11 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A547E18607F66 for ; Thu, 9 Dec 2021 13:00:01 +0000 (UTC) X-FDA: 78898263402.28.239C6B1 Received: from gentwo.de (gentwo.de [161.97.139.209]) by imf28.hostedemail.com (Postfix) with ESMTP id 1292EC0008 for ; Thu, 9 Dec 2021 13:00:00 +0000 (UTC) Received: by gentwo.de (Postfix, from userid 1001) id E7ED2B00229; Thu, 9 Dec 2021 13:59:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id E6A62B0019A; Thu, 9 Dec 2021 13:59:58 +0100 (CET) Date: Thu, 9 Dec 2021 13:59:58 +0100 (CET) From: Christoph Lameter X-X-Sender: cl@gentwo.de To: Baoquan He cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de, robin.murphy@arm.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, m.szyprowski@samsung.com, John.p.donnelly@oracle.com, kexec@lists.infradead.org Subject: Re: [PATCH RESEND v2 0/5] Avoid requesting page from DMA zone when no managed pages In-Reply-To: <20211209080540.GA3050@MiWiFi-R3L-srv> Message-ID: References: <20211207030750.30824-1-bhe@redhat.com> <20211209080540.GA3050@MiWiFi-R3L-srv> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1292EC0008 X-Stat-Signature: uw3htop3h85ncmp85qor575gjqnak7y6 Authentication-Results: imf28.hostedemail.com; dkim=none; spf=none (imf28.hostedemail.com: domain of cl@gentwo.org has no SPF policy when checking 161.97.139.209) smtp.mailfrom=cl@gentwo.org; dmarc=none X-HE-Tag: 1639054800-870805 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 9 Dec 2021, Baoquan He wrote: > > The slab allocators guarantee that all kmalloc allocations are DMA able > > indepent of specifying ZONE_DMA/ZONE_DMA32 > > Here you mean we guarantee dma-kmalloc will be DMA able independent of > specifying ZONE_DMA/DMA32, or the whole sla/ub allocator? All memory obtained via kmalloc --independent of "dma-alloc", ZONE_DMA etc-- must be dmaable. > With my understanding, isn't the reasonable sequence zone DMA firstly if > GFP_DMA, then zone DMA32, finaly zone NORMAL. At least, on x86_64, I > believe device driver developer prefer to see this because most of time, > zone DMA and zone DMA32 are both used for dma buffer allocation, if > IOMMU is not enabled. However, memory got from zone NORMAL when required > with GFP_DMA, and it succeeds, does it mean that the developer doesn't > take the GFP_DMA flag seriously, just try to get buffer for allocation? ZONE_NORMAL is also used for DMA allocations. ZONE_DMA and ZONE_DMA32 are only used if the physical range of memory supported by a device does not include all of normal memory. > > The size of ZONE_DMA is traditionally depending on the platform. On some > > it is 16MB, on some 1G and on some 4GB. ZONE32 is always 4GB and should > > only be used if ZONE_DMA has already been used. > > As said at above, ia64 and riscv don't have ZONE_DMA at all, they just > cover low 4G with ZONE_DMA32 alone. If you do not have devices that are crap and cannot address the full memory then you dont need these special zones. Sorry this subject has caused confusion multiple times over the years and there are still arches that are not implementing this in a consistent way.