Hi, > > No, it's a measurable value- not subjective. I wasn't talking about the performance number but rather about "acceptable". Some may argue that for certain drivers the slight reduction in performance is more than compensated by the several benefits that an IOMMU offers (note that SPARC side has been functioning with IOMMU without complaints about performance). For certain drivers it may turn out that the owners find the performance reduction undesirable. It all depends on the driver owners.
>> We have always planned to provide the ability to disable the IOMMU on >> a per driver basis. Does that address your performance concerns ? >> > Yes, but as this is a spec in advance of actual implementation, could > you make sure that 'plan' is on record? ok, I will send an addendum to the spec shortly. Vikram Matthew Jacob wrote: > On 09/03/08 17:07, 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). > > No, it's a measurable value- not subjective. > >> We have always planned to provide the ability to disable the IOMMU on >> a per driver basis. Does that address your performance concerns ? >> > > Yes, but as this is a spec in advance of actual implementation, could > you make sure that 'plan' is on record? >
