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 4FA1DC5479D for ; Wed, 11 Jan 2023 16:19:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D91C48E0002; Wed, 11 Jan 2023 11:19:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D42AE8E0001; Wed, 11 Jan 2023 11:19:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C09688E0002; Wed, 11 Jan 2023 11:19:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B14AC8E0001 for ; Wed, 11 Jan 2023 11:19:13 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7A4E9160BB4 for ; Wed, 11 Jan 2023 16:19:13 +0000 (UTC) X-FDA: 80343027786.18.13BA8A8 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id BB0D1140010 for ; Wed, 11 Jan 2023 16:19:11 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="oUm4vmx/"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673453952; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9Uo1F/S6/BtgInuYAgaI0yUjIL9CeDbM27HnRNyBOC8=; b=vksLKpqXBbfBdx8bGybLy+7sWxXizisWw40NO/8Yus3GtZAyJe5yxAFAVuhzcJZDLJP4rE U3U6wBw3TXYDJD5hzNZ0Jfx5IGW6MoPCzWVOAUOplc4cDGUhzbf2es/NA8ejUWCgdBPoMx h/UivEX98EaojTVi0Y1TmVFYCKNktXs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="oUm4vmx/"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673453952; a=rsa-sha256; cv=none; b=cQc4viZ+KSUR+iv3nxBwL2ITNChttjzybWLiQC+h0wJ/ffeOLpGEf+hfneGetbY4STqQpc PwoqyRQNuEzLKMIROp9Uz/YotEgwTve7A8+oGZsKwaXeCQEwxerXQkN/EFeHcIkFYBpsaG on7R6g4TBsjsfgnG6sx6BVyqmgFq6JE= 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 3F6B44DEB; Wed, 11 Jan 2023 16:19:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673453950; 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=9Uo1F/S6/BtgInuYAgaI0yUjIL9CeDbM27HnRNyBOC8=; b=oUm4vmx/tY5jshUMzmTMV4ujxm9WBPq7G63760MdNaeUeWGw61qJWUsBiU/ThcpJxf3YbT 9dnFhOb83o/uIlG01AUWYKBRHbBej41yxRsJGPGrJM6vF20xCc+ljCnJ/Ur+izcnctbDnB +W6AaANj1nk+G3E8ZdNbT5nkdMWH1UE= 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 1EC6B1358A; Wed, 11 Jan 2023 16:19:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id aLOxBX7hvmPZTgAAMHmgww (envelope-from ); Wed, 11 Jan 2023 16:19:10 +0000 Date: Wed, 11 Jan 2023 17:19:09 +0100 From: Michal Hocko To: Mike Rapoport Cc: Jonathan Corbet , Andrew Morton , Bagas Sanjaya , David Hildenbrand , Johannes Weiner , Lorenzo Stoakes , "Matthew Wilcox (Oracle)" , Mel Gorman , Vlastimil Babka , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 2/2] docs/mm: Physical Memory: add structure, introduction and nodes description Message-ID: References: <20230110152358.2641910-1-rppt@kernel.org> <20230110152358.2641910-3-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BB0D1140010 X-Stat-Signature: zspoirdd1zgiwwd9gduwu1jgkeihe4xn X-HE-Tag: 1673453951-730458 X-HE-Meta: U2FsdGVkX19rTp+CW8bAJb+YGvWF9rYqlVe2bnDgCQxQEHEZqUE3zLWHH+wmMnZeV1wtzjm4gpAp2gvPpkrcohDz8xp9h5ajRAZG5NpyQvye9b4j9p45/4CkoACSs9kmzzSEJPh/TgYEAvFaRPXl4lqfUVZbNCMwfU+q9Cx0Qlr+0WzgcCOI0jDDoBdp+5xiZa5R3e4Rv5Kou1vTIynCQ4LNc37c35+J7lpke6jB9h6fzpGGT1vyVbl1u4D3aE1idGHRdTLn+xXumjv1vTSHfkqNee8aef6TGLKqHWDc0/7C1O0O84tD/7xjgjZTZqcF+1XvcDZtodqLKmqxL4x9HPaB3i2KJMUJt1KCA8A4eMnOEdQC298+F296W9vXJxbMxYrj6lKyvwbt5kyfQ9FUgYp5eppZ9so6JCzGZDf9uHjyXE/J3YQIlfyxR/7QQ/XS9BxCUa6UZuPsf5EYUnSyM6lAgHUpZ0EZMojhzlPfx+GqdyUw4AbCIdqkXsTgq1D16dWkTt1pmh4PZ+NruBMt3b55fhWjYlrurEroil1BdiTBOrPITAuhtLLZcAxt4qX7SvOupj7NdlvLIJUBh9NzXe+tmOCrAXSQAz8LBWEyjH008msKYaJLmMMkXhOCwOnmI6mEMPJB+ySLXpP+57f2l6ZkX4wTcziMmO+5BoB3bLnlIRe3eqHnZtY9S58eDgbKD4FyuN6yllPsYaSSzgmq2iyPCYi9uaJ8nMK8lQcngTeHtaSLRNnawMeQg6kYCwLfb3in6DkQcngu9yff4L8NMyG8qo840396jR5XPKlRbjwQJNgaQbmCKagHN+4UnkorY3kCT48FZNHKYVKoSWvwbflITvAkPEb88Vx1+UNhK/iEkkqJi5oX7w== 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 Wed 11-01-23 18:02:03, Mike Rapoport wrote: > On Wed, Jan 11, 2023 at 02:36:16PM +0100, Michal Hocko wrote: > > On Wed 11-01-23 14:24:43, Mike Rapoport wrote: > > > On Tue, Jan 10, 2023 at 05:54:10PM +0100, Michal Hocko wrote: > > > > On Tue 10-01-23 17:23:58, Mike Rapoport wrote: > > > > [...] > > > > > +* ``ZONE_DMA`` and ``ZONE_DMA32`` represent memory suitable for DMA by > > > > > + peripheral devices that cannot access all of the addressable memory. > > > > > > > > I think it would be better to not keep the historical DMA based menaning > > > > and teach that future developers. You can say something like > > > > > > > > ZONE_DMA and ZONE_DMA32 have historically been used for memory suitable > > > > for DMA. For many years there are better more robust interfaces to > > > > get memory with DMA specific requirements (Documentation/core-api/dma-api.rst). > > > > > > But even today ZONE_DMA(32) means that the memory is suitable for DMA. This > > > is nicely encapsulated with dma APIs and there should be no new GFP_DMA > > > users, but still memory outside ZONE_DMA is not suitable for DMA. > > > > Well, the thing is that ZONE_DMA means different thing for different > > architectures. For x86 it is effectivelly about ISA attached HW - which > > means almost nothing these days. There is plethora of other HW with > > different address range constrains for DMA transfer so binding the zone > > with DMA is more likely to cause confusion than it helps. > > Ok, how about > > * ``ZONE_DMA`` and ``ZONE_DMA32`` historically represented memory suitable for > DMA by peripheral devices that cannot access all of the addressable > memory. For many years there are better more and robust interfaces to get > memory with DMA specific requirements (:ref:`DMA API <_dma_api>`), but > ``ZONE_DMA`` and ``ZONE_DMA32`` still represent memory ranges that have > restrictions on how they can be accessed. > Depending on the architecture, either of these zone types or even they both > can be disabled at build time using ``CONFIG_ZONE_DMA`` and > ``CONFIG_ZONE_DMA32`` configuration options. Some 64-bit platforms may need > both zones as they support peripherals with different DMA addressing > limitations. Sounds better to me. Thanks! At least ZONE_DMA32 is somehow better defined as it represents 32b address range constrain. DMA can be really different on different arches. Probably good to have it here. Ideally we would have a reference how that range is established but architectures are not unified in that respect. -- Michal Hocko SUSE Labs