[PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone

[Hyeonggon Yoo]

Hello Christoph.

On Tue, Dec 21, 2021 at 09:56:23AM +0100, Christoph Hellwig wrote:
> 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.

Oh I misunderstood this. Underlying physical address of vmalloc()-allocated memory
can be mapped using DMA API, and it needs to be setup as scatterlist because
the allocated memory is not physically continuous. Right?

BTW, looking at the API I think the scsi case can be converted to use
dma_alloc_pages(). but driver requires 512 bytes of buffer and the API
supports allocating by at least page size.

It's not a big problem as it allocates a single buffer but in other
cases maybe not. Can't we use dma pool for non-coherent pages?

Thanks,
Hyeonggon.

> > 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.