[RFC 0/7] Introduce swiotlb throttling

Michael Kelley mhklinux at outlook.com
Thu Aug 22 19:20:41 PDT 2024


From: Bart Van Assche <bvanassche at acm.org> Sent: Thursday, August 22, 2024 12:29 PM
> 
> On 8/22/24 11:37 AM, mhkelley58 at gmail.com wrote:
> > Linux device drivers may make DMA map/unmap calls in contexts that
> > cannot block, such as in an interrupt handler.
> 
> Although I really appreciate your work, what alternatives have been
> considered? How many drivers perform DMA mapping from atomic context?
> Would it be feasible to modify these drivers such that DMA mapping
> always happens in a context in which sleeping is allowed?
> 

I had assumed that allowing DMA mapping from interrupt context is a
long-time fundamental requirement that can't be changed.  It's been
allowed at least for the past 20 years, as Linus added this statement to
kernel documentation in 2005:

   The streaming DMA mapping routines can be called from interrupt context.

But I don't have any idea how many drivers actually do that. There are
roughly 1700 call sites in kernel code/drivers that call one of the
dma_map_*() variants, so looking through them all doesn't seem
feasible. From the limited samples I looked at, block device drivers
typically do not call dma_map_*() from interrupt context, though they
do call dma_unmap_*(). Network drivers _do_ call dma_map_*()
from interrupt context, and that seems likely to be an artifact of the
generic networking framework that the drivers fit into. I haven't looked
at any other device types. 

Christoph Hellwig, or anyone else who knows the history and current
reality better than I do, please jump in. :-)

Michael


More information about the Linux-nvme mailing list