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;
Date:   Wed, 11 Jan 2023 17:19:09 +0100
From:   Michal Hocko <mhocko@suse.com>
To:     Mike Rapoport <rppt@kernel.org>
Cc:     Jonathan Corbet <corbet@lwn.net>,
        Andrew Morton <akpm@linux-foundation.org>,
        Bagas Sanjaya <bagasdotme@gmail.com>,
        David Hildenbrand <david@redhat.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Lorenzo Stoakes <lstoakes@gmail.com>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
        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: <Y77hfY8+FUun1tKa@dhcp22.suse.cz>
References: <20230110152358.2641910-1-rppt@kernel.org>
 <20230110152358.2641910-3-rppt@kernel.org>
 <Y72YMk21sSJLfUiz@dhcp22.suse.cz>
 <Y76qi7OB0gcigqZA@kernel.org>
 <Y767UIx0TQtylJPG@dhcp22.suse.cz>
 <Y77de+xRh+8NXXKn@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y77de+xRh+8NXXKn@kernel.org>
Precedence: bulk

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