On Fri, 23 Aug 2024 20:40:16 +0000 Michael Kelley <mhklinux@xxxxxxxxxxx> wrote: > From: Petr Tesařík <petr@xxxxxxxxxxx> Sent: Thursday, August 22, 2024 11:45 PM >[...] > > > Discussion > > > ========== > > > * Since swiotlb isn't visible to device drivers, I've specifically > > > named the DMA attribute as MAY_BLOCK instead of MAY_THROTTLE or > > > something swiotlb specific. While this patch set consumes MAY_BLOCK > > > only on the DMA direct path to do throttling in the swiotlb code, > > > there might be other uses in the future outside of CoCo VMs, or > > > perhaps on the IOMMU path. > > > > I once introduced a similar flag and called it MAY_SLEEP. I chose > > MAY_SLEEP, because there is already a might_sleep() annotation, but I > > don't have a strong opinion unless your semantics is supposed to be > > different from might_sleep(). If it is, then I strongly prefer > > MAY_BLOCK to prevent confusing the two. > > My intent is that the semantics are the same as might_sleep(). I > vacillated between MAY_SLEEP and MAY_BLOCK. The kernel seems > to treat "sleep" and "block" as equivalent, because blk-mq has > the BLK_MQ_F_BLOCKING flag, and SCSI has the > queuecommand_may_block flag that is translated to > BLK_MQ_F_BLOCKING. So I settled on MAY_BLOCK, but as you > point out, that's inconsistent with might_sleep(). Either way will > be inconsistent somewhere, and I don't have a preference. Fair enough. Let's stay with MAY_BLOCK then, so you don't have to change it everywhere. >[...] > > > Open Topics > > > =========== > > > 1. swiotlb allocations from Xen and the IOMMU code don't make use > > > of throttling. This could be added if beneficial. > > > > > > 2. The throttling values are currently exposed and adjustable in > > > /sys/kernel/debug/swiotlb. Should any of this be moved so it is > > > visible even without CONFIG_DEBUG_FS? > > > > Yes. It should be possible to control the thresholds through > > sysctl. > > Good point. I was thinking about creating /sys/kernel/swiotlb, but > sysctl is better. That still leaves the question where it should go. Under /proc/sys/kernel? Or should we make a /proc/sys/kernel/dma subdirectory to make room for more dma-related controls? Petr T
