[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211221085623.GA7733@lst.de>
Date: Tue, 21 Dec 2021 09:56:23 +0100
From: Christoph Hellwig <hch@....de>
To: Hyeonggon Yoo <42.hyeyoo@...il.com>
Cc: Baoquan He <bhe@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, akpm@...ux-foundation.org, hch@....de,
cl@...ux.com, John.p.donnelly@...cle.com,
kexec@...ts.infradead.org, stable@...r.kernel.org,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no
managed pages in DMA zone
On Fri, Dec 17, 2021 at 11:38:27AM +0000, Hyeonggon Yoo wrote:
> My understanding is any buffer requested from kmalloc (without
> GFP_DMA/DMA32) can be used by device driver because it allocates
> continuous physical memory. It doesn't mean that buffer allocated
> with kmalloc is free of addressing limitation.
Yes.
>
> the addressing limitation comes from the capability of device, not
> allocation size. if you allocate memory using alloc_pages() or kmalloc(),
> the device has same limitation. and vmalloc can't be used for
> devices because they have no MMU.
vmalloc can be used as well, it just needs to be setup as a scatterlist
and needs a little lover for DMA challenged platforms with the
invalidate_kernel_vmap_range and flush_kernel_vmap_range helpers.
> But we can map memory outside DMA zone into bounce buffer (which resides
> in DMA zone) using DMA API.
Yes, although in a few specific cases the bounce buffer could also come
from somewhere else.
Powered by blists - more mailing lists