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 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.
-- Garrett
>
> Vikram
>
>
> Matthew Jacob wrote:
>> On 09/03/08 16:34, Jerry Gilliam wrote:
>>> I am sponsoring the following fast-track for Vikram Hegde. This
>>> case presents an overview and architectural details on an IOMMU
>>> for AMD cpus. This information is being presented for information
>>> only, for discussion and future reference. As there's nothing to
>>> approve, I believe Closed Approved Automatic is appropriate.
>>>
>>>
>>>
>>>
>>
>> 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.
>
