On Wed, Dec 15, 2021 at 08:27:10AM +0100, Christoph Hellwig wrote:

On Wed, Dec 15, 2021 at 07:03:35AM +0000, Hyeonggon Yoo wrote:

quoted

I'm not sure that allocating from ZONE_DMA32 instead of ZONE_DMA
for kdump kernel is nice way to solve this problem.

What is the problem with zones in kdump kernels?

quoted

Devices that requires ZONE_DMA memory is rare but we still support them.

Indeed.

quoted

quoted

    1) Do not call warn_alloc in page allocator if will always fail
    to allocate ZONE_DMA pages.


    2) let's check all callers of kmalloc with GFP_DMA
    if they really need GFP_DMA flag and replace those by DMA API or
    just remove GFP_DMA from kmalloc()

    3) Drop support for allocating DMA memory from slab allocator
    (as Christoph Hellwig said) and convert them to use DMA32

	(as Christoph Hellwig said) and convert them to use *DMA API*

quoted

    and see what happens

This is the right thing to do, but it will take a while.  In fact
I dont think we really need the warning in step 1,

Hmm I think step 1) will be needed if someone is allocating pages from
DMA zone not using kmalloc or DMA API. (for example directly allocating
from buddy allocator) is there such cases?

a simple grep
already allows to go over them.  I just looked at the uses of GFP_DMA
in drivers/scsi for example, and all but one look bogus.

That's good. this cleanup will also remove unnecessary limitations.

quoted

quoted

quoted

quoted

Yeah, I have the same guess too for get_capabilities(), not sure about other
callers. Or, as ChristophL and ChristophH said(Sorry, not sure if this is
the right way to call people when the first name is the same. Correct me if
it's wrong), any buffer requested from kmalloc can be used by device driver.
Means device enforces getting memory inside addressing limit for those
DMA transferring buffer which is usually large, Megabytes level with
vmalloc() or alloc_pages(), but doesn't care about this kind of small
piece buffer memory allocated with kmalloc()? Just a guess, please tell
a counter example if anyone happens to know, it could be
easy.

The way this works is that the dma_map* calls will bounce buffer memory
that does to fall into the addressing limitations.  This is a performance
overhead, but allows drivers to address all memory in a system.  If the
driver controls memory allocation it should use one of the dma_alloc_*
APIs that allocate addressable memory from the start.  The allocator
will dip into ZONE_DMA and ZONE_DMA32 when needed.