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
