Interesting that they allocate a whopping 64MB, I thought DMA transfers are done using a few KB at a time? Even if several devices operating in parallel must be supported, that still seems like a lot?

Perhaps there are scenarios where larger buffers are useful; I supppose getting an interrupt every 4 kilobytes transferred could be a decent performance hit with some devices, like a hardware /dev/null accelerator. If these numbers are what I think they are, then in my systems it's not used a lot:

    % sudo grep . /sys/kernel/debug/swiotlb/{io_tlb_nslabs,io_tlb_used}
    /sys/kernel/debug/swiotlb/io_tlb_nslabs:32768
    /sys/kernel/debug/swiotlb/io_tlb_used:4

My other systems used 0-2.

/dev/null maps the same zeroed page over and over

I see two use cases for a "big" swiotlb buffer: (1) many devices concurrently, as you said, or (2) ring buffers for devices that write continuously. Combine both and you require even more space; knowing the usecase and doing testing becomes required at this point.

While looking into it I found this guy wanting 64 MB swiotlb who was probably doing something like that: https://stackoverflow.com/questions/52833714/change-the-size...

Looks like an exception to the rule, though.

I've worked on a project that required a bigger swiotlb as well, I don't remember the exact details though. I guess it's not that uncommon, but indeed the default value looks good.