From: Christoph Lameter <cl@gentwo.org> To: Baoquan He <bhe@redhat.com> Cc: 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: Tue, 7 Dec 2021 09:05:26 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.2.22.394.2112070859420.201880@gentwo.de> (raw) In-Reply-To: <20211207030750.30824-1-bhe@redhat.com> 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 > 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. > 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. ZONE_DMA is dynamic in the sense of being different on different platforms. Generally I guess it would be possible to use ZONE_DMA for generic tagging of special memory that can be configured to have a dynamic size but that is not what it was designed to do.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@gentwo.org> To: Baoquan He <bhe@redhat.com> Cc: 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: Tue, 7 Dec 2021 09:05:26 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.2.22.394.2112070859420.201880@gentwo.de> (raw) In-Reply-To: <20211207030750.30824-1-bhe@redhat.com> 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 > 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. > 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. ZONE_DMA is dynamic in the sense of being different on different platforms. Generally I guess it would be possible to use ZONE_DMA for generic tagging of special memory that can be configured to have a dynamic size but that is not what it was designed to do. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-12-07 8:05 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 [this message] 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 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=alpine.DEB.2.22.394.2112070859420.201880@gentwo.de \ --to=cl@gentwo.org \ --cc=John.p.donnelly@oracle.com \ --cc=akpm@linux-foundation.org \ --cc=bhe@redhat.com \ --cc=hch@lst.de \ --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.