Skip to content

Improve handling of GFP flags in the CMA allocator

Gabriel Krisman Bertazi linux-mm 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest6 patches 4 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/6Revert "kernel/dma: remove unsupported gfp_mask parameter from dma_alloc_from_contiguous()"arch/arm/mm/dma-mapping.c arch/arm64/mm/dma-mapping.c arch/xtensa/kernel/pci-dma.c +6 more+14 -160 replies
2/6Revert "mm/cma: remove unsupported gfp_mask parameter from cma_alloc()"arch/powerpc/kvm/book3s_hv_builtin.c drivers/s390/char/vmcp.c drivers/staging/android/ion/ion_cma_heap.c +4 more+10 -110 replies
3/6cma: Warn about callers requesting unsupported flagsmm/cma.c+4 -00 replies
4/6cma: Add support for GFP_ZEROmm/cma.c+10 -20 replies
5/6page_isolation: Propagate temporary pageblock isolation errormm/page_isolation.c+13 -70 replies
6/6cma: Isolate pageblocks speculatively during allocationmm/cma.c+26 -30 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/6] Improve handling of GFP flags in the CMA allocator

Hi,

The main goal of this patchset is to solve a deadlock in the CMA allocator, which happens because cma_alloc tries to sleep waiting for an IO in the GFP_NOIO path. This issue, which was reported by Gael Portay was discussed here:

https://groups.google.com/a/lists.one-eyed-alien.net/forum/#!topic/usb-storage/BXpAsg-G1us

My proposed requires reverting the patches that removed the gfp flags information from cma_alloc() (patches 1 to 3). According to the author, that parameter was removed because it misleads developers about what cma_alloc actually supports. In his specific case he had problems with GFP_ZERO. With that in mind I gave a try at implementing GFP_ZERO in a quite trivial way in patch 4. Finally, patches 5 and 6 attempt to fix the issue by avoiding the unecessary serialization done around alloc_contig_range.

This is my first adventure in the mm subsystem, so I hope I didn't screw up something very obvious. I tested this on the workload that was deadlocking (arm board, with CMA intensive operations from the GPU and USB), as well as some scripting on top of debugfs. Is there any regression test I should be running, which specially applies to the CMA code?

Gabriel Krisman Bertazi (6):
Revert "kernel/dma: remove unsupported gfp_mask parameter from
dma_alloc_from_contiguous()"
Revert "mm/cma: remove unsupported gfp_mask parameter from

    cma_alloc()"

cma: Warn about callers requesting unsupported flags
cma: Add support for GFP_ZERO
page_isolation: Propagate temporary pageblock isolation error
cma: Isolate pageblocks speculatively during allocation

 arch/arm/mm/dma-mapping.c                  |  5 +--
 arch/arm64/mm/dma-mapping.c                |  2 +-
 arch/powerpc/kvm/book3s_hv_builtin.c       |  2 +-
 arch/xtensa/kernel/pci-dma.c               |  2 +-
 drivers/iommu/amd_iommu.c                  |  2 +-
 drivers/iommu/intel-iommu.c                |  3 +-
 drivers/s390/char/vmcp.c                   |  2 +-
 drivers/staging/android/ion/ion_cma_heap.c |  2 +-
 include/linux/cma.h                        |  2 +-
 include/linux/dma-contiguous.h             |  4 +-
 kernel/dma/contiguous.c                    |  6 +--
 kernel/dma/direct.c                        |  3 +-
 kernel/dma/remap.c                         |  2 +-
 mm/cma.c                                   | 51 ++++++++++++++++++----
 mm/cma_debug.c                             |  2 +-
 mm/page_isolation.c                        | 20 ++++++---
 16 files changed, 74 insertions(+), 36 deletions(-)
Signature · 1 line
2.20.1