Garrett D'Amore wrote: > Vikram Hegde wrote: >> Hi, >> >>> Abilities to disable the IOMMU as a choice? Performance impact on >>> various systems and interactions with other projects that have gone >>> to some length to work within S/G and its performance >>> characteristics. How will this affect them? Cache effects? >>> Interactions with some VM work currently being undertaken? >>> >>> I can't imagine such a major change being closed/approved/automatic. >> Performance is driver dependant. There is no way a single project >> team can test the gamut of drivers out there and certify that the >> IOMMU will give acceptable performance for all needs (which is >> itself a subjective opinion). We have always planned to provide the >> ability to disable the IOMMU on a per driver basis. Does that address >> your performance concerns ? > > Actually, for many cases, IOMMU may *improve* performance. This is > because it will make it easier to satisfy device constraints for DMA > resources without requiring the use of a bounce buffer or dma windows.
That is almost always the exception now. The other issue IIRC is the interaction between the IOMMU and memory caches. In many data movement appliance contexts you use scatter-gather (scatter-gather in name only- contiguous memory is good) to physical pages which are never mapped in. The main point here is to avoid a situation that we're currently in now with respect MSI-X and Interrupt/CPU binding and make sure that there are sufficient control surfaces to allow for a broad range of possible implementation choices. > > That said, drivers which assume that setup and tear down of DMA is > "cheap" may take a perf. hit when using an IOMMU. This is already the > case for SPARC systems, btw. Except for those (ancient) ones that used 36-bit MBus physical addresses and bypassed the IOMMU.
