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
next prev 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: linkBe 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.