All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christoph Lameter <cl@gentwo.org>
Cc: Baoquan He <bhe@redhat.com>,
	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
Date: Mon, 13 Dec 2021 08:47:21 +0100	[thread overview]
Message-ID: <20211213074721.GB20758@lst.de> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2112070859420.201880@gentwo.de>

On Tue, Dec 07, 2021 at 09:05:26AM +0100, Christoph Lameter wrote:
> On Tue, 7 Dec 2021, Baoquan He wrote:
> 
> > into ZONE_DMA32 by default. The zone DMA covering low 16M is used to
> > take care of antique ISA devices. In fact, on 64bit system, it rarely
> > need ZONE_DMA (which is low 16M) to support almost extinct ISA devices.
> > However, some components treat DMA as a generic concept, e.g
> > kmalloc-dma, slab allocator initializes it for later any DMA related
> > buffer allocation, but not limited to ISA DMA.
> 
> The idea of the slab allocator DMA support is to have memory available
> for devices that can only support a limited range of physical addresses.
> These are only to be enabled for platforms that have such requirements.
> 
> The slab allocators guarantee that all kmalloc allocations are DMA able
> indepent of specifying ZONE_DMA/ZONE_DMA32

Yes.  And we never supported slab for ZONE_DMA32 and should work on
getting rid of it for ZONE_DMA as well.  The only thing that guarantees
device addressability is the DMA API.  The DMA API needs ZONE_DMA/DMA32
to back its page allocations, but supporting this in slab is a bad idea
only explained by historic reasons from before when we had a DMA API.

> > On arm64, even though both CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32
> > are enabled, it makes ZONE_DMA covers the low 4G area, and ZONE_DMA32
> > empty. Unless on specific platforms (e.g. 30-bit on Raspberry Pi 4),
> > then zone DMA covers the 1st 1G area, zone DMA32 covers the rest of
> > the 32-bit addressable memory.
> 
> ZONE_NORMAL should cover all memory. ARM does not need ZONE_DMA32.

arm32 not, arm64 does.  And the Pi 4 is an arm64 device.

> > I am wondering if we can also change the size of DMA and DMA32 ZONE as
> > dynamically adjusted, just as arm64 is doing? On x86_64, we can make
> > zone DMA covers the 32-bit addressable memory, and empty zone DMA32 by
> > default. Once ISA_DMA_API is enabled, we go back to make zone DMA covers
> > low 16M area, zone DMA32 covers the rest of 32-bit addressable memory.
> > (I am not familiar with ISA_DMA_API, will it require 24-bit addressable
> > memory when enabled?)
> 
> 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.

ZONE32 should be (and generally is) used whenever there is zone covering
the 32-bit CPU physical address limit.

> 
> ZONE_DMA is dynamic in the sense of being different on different
> platforms.

Agreed.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Christoph Lameter <cl@gentwo.org>
Cc: Baoquan He <bhe@redhat.com>,
	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
Date: Mon, 13 Dec 2021 08:47:21 +0100	[thread overview]
Message-ID: <20211213074721.GB20758@lst.de> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2112070859420.201880@gentwo.de>

On Tue, Dec 07, 2021 at 09:05:26AM +0100, Christoph Lameter wrote:
> On Tue, 7 Dec 2021, Baoquan He wrote:
> 
> > into ZONE_DMA32 by default. The zone DMA covering low 16M is used to
> > take care of antique ISA devices. In fact, on 64bit system, it rarely
> > need ZONE_DMA (which is low 16M) to support almost extinct ISA devices.
> > However, some components treat DMA as a generic concept, e.g
> > kmalloc-dma, slab allocator initializes it for later any DMA related
> > buffer allocation, but not limited to ISA DMA.
> 
> The idea of the slab allocator DMA support is to have memory available
> for devices that can only support a limited range of physical addresses.
> These are only to be enabled for platforms that have such requirements.
> 
> The slab allocators guarantee that all kmalloc allocations are DMA able
> indepent of specifying ZONE_DMA/ZONE_DMA32

Yes.  And we never supported slab for ZONE_DMA32 and should work on
getting rid of it for ZONE_DMA as well.  The only thing that guarantees
device addressability is the DMA API.  The DMA API needs ZONE_DMA/DMA32
to back its page allocations, but supporting this in slab is a bad idea
only explained by historic reasons from before when we had a DMA API.

> > On arm64, even though both CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32
> > are enabled, it makes ZONE_DMA covers the low 4G area, and ZONE_DMA32
> > empty. Unless on specific platforms (e.g. 30-bit on Raspberry Pi 4),
> > then zone DMA covers the 1st 1G area, zone DMA32 covers the rest of
> > the 32-bit addressable memory.
> 
> ZONE_NORMAL should cover all memory. ARM does not need ZONE_DMA32.

arm32 not, arm64 does.  And the Pi 4 is an arm64 device.

> > I am wondering if we can also change the size of DMA and DMA32 ZONE as
> > dynamically adjusted, just as arm64 is doing? On x86_64, we can make
> > zone DMA covers the 32-bit addressable memory, and empty zone DMA32 by
> > default. Once ISA_DMA_API is enabled, we go back to make zone DMA covers
> > low 16M area, zone DMA32 covers the rest of 32-bit addressable memory.
> > (I am not familiar with ISA_DMA_API, will it require 24-bit addressable
> > memory when enabled?)
> 
> 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.

ZONE32 should be (and generally is) used whenever there is zone covering
the 32-bit CPU physical address limit.

> 
> ZONE_DMA is dynamic in the sense of being different on different
> platforms.

Agreed.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2021-12-13  7:47 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07  3:07 [PATCH RESEND v2 0/5] Avoid requesting page from DMA zone when no managed pages Baoquan He
2021-12-07  3:07 ` Baoquan He
2021-12-07  3:07 ` [PATCH RESEND v2 1/5] docs: kernel-parameters: Update to reflect the current default size of atomic pool Baoquan He
2021-12-07  3:07   ` Baoquan He
2021-12-07  3:53   ` John Donnelly
2021-12-07  3:53     ` John Donnelly
2021-12-07  3:07 ` [PATCH RESEND v2 2/5] dma-pool: allow user to disable " Baoquan He
2021-12-07  3:07   ` Baoquan He
2021-12-07  3:53   ` John Donnelly
2021-12-07  3:53     ` John Donnelly
2021-12-13  7:44   ` Christoph Hellwig
2021-12-13  7:44     ` Christoph Hellwig
2021-12-13  8:16     ` Baoquan He
2021-12-13  8:16       ` Baoquan He
2021-12-07  3:07 ` [PATCH RESEND v2 3/5] mm_zone: add function to check if managed dma zone exists Baoquan He
2021-12-07  3:07   ` Baoquan He
2021-12-07  3:53   ` John Donnelly
2021-12-07  3:53     ` John Donnelly
2021-12-07 11:23   ` David Hildenbrand
2021-12-07 11:23     ` David Hildenbrand
2021-12-09 13:02     ` Baoquan He
2021-12-09 13:02       ` Baoquan He
2021-12-09 13:10       ` David Hildenbrand
2021-12-09 13:10         ` David Hildenbrand
2021-12-09 13:23         ` Baoquan He
2021-12-09 13:23           ` Baoquan He
2021-12-07  3:07 ` [PATCH RESEND v2 4/5] dma/pool: create dma atomic pool only if dma zone has managed pages Baoquan He
2021-12-07  3:07   ` Baoquan He
2021-12-07  3:07   ` Baoquan He
2021-12-07  3:54   ` John Donnelly
2021-12-07  3:54     ` John Donnelly
2021-12-07  3:54     ` John Donnelly
2021-12-07  3:07 ` [PATCH RESEND v2 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone Baoquan He
2021-12-07  3:07   ` Baoquan He
2021-12-07  3:54   ` John Donnelly
2021-12-07  3:54     ` John Donnelly
2021-12-07  3:16 ` [PATCH RESEND v2 0/5] Avoid requesting page from DMA zone when no managed pages Baoquan He
2021-12-07  3:16   ` Baoquan He
2021-12-07  4:03   ` John Donnelly
2021-12-07  4:03     ` John Donnelly
2021-12-08  4:33     ` Andrew Morton
2021-12-08  4:33       ` Andrew Morton
2021-12-08  4:56       ` John Donnelly
2021-12-08  4:56         ` John Donnelly
2021-12-13  3:54     ` Baoquan He
2021-12-13  3:54       ` Baoquan He
2021-12-13 13:25   ` Borislav Petkov
2021-12-13 13:25     ` Borislav Petkov
2021-12-13 14:03     ` Baoquan He
2021-12-13 14:03       ` Baoquan He
2021-12-07  8:05 ` Christoph Lameter
2021-12-07  8:05   ` Christoph Lameter
2021-12-09  8:05   ` Baoquan He
2021-12-09  8:05     ` Baoquan He
2021-12-09 12:59     ` Christoph Lameter
2021-12-09 12:59       ` Christoph Lameter
2021-12-13  7:39       ` Baoquan He
2021-12-13  7:39         ` Baoquan He
2021-12-13  7:49         ` Christoph Hellwig
2021-12-13  7:49           ` Christoph Hellwig
2021-12-13 14:21       ` Hyeonggon Yoo
2021-12-13 14:21         ` Hyeonggon Yoo
2021-12-13  7:47   ` Christoph Hellwig [this message]
2021-12-13  7:47     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211213074721.GB20758@lst.de \
    --to=hch@lst.de \
    --cc=John.p.donnelly@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=cl@gentwo.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=robin.murphy@arm.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.