lkml.org 
[lkml]   [2023]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v4] iommu: Optimise PCI SAC address trick
From
On 15/06/2023 10:04, Robin Murphy wrote:
>> Since we're at rc6 time and a cautious approach was wanted to merge
>> this change, I doubt that this will be merged for this cycle. That's
>> quite unfortunate.
>>
>> Please note what I mentioned earlier about using
>> dma_opt_mapping_size(). This API is used by some block storage drivers
>> to avoid your same problem, by clamping max_sectors_kb at this size -
>> see sysfs-block Doc for info there. Maybe it can be used similarly for
>> network drivers.
>
> It's not the same problem - in this case the mappings are already small
> enough to use the rcaches, and it seems more to do with the total number
> of unusable cached IOVAs being enough to keep the 32-bit space
> almost-but-not-quite full most of the time, defeating the
> max32_alloc_size optimisation whenever the caches run out of the right
> size entries.

Sure, not the same problem.

However when we switched storage drivers to use dma_opt_mapping_size()
then performance is similar to iommu.forcedac=1 - that's what I found,
anyway.

This tells me that that even though IOVA allocator performance is poor
when the 32b space fills, it was those large IOVAs which don't fit in
the rcache which were the major contributor to hogging the CPU in the
allocator.

>
> The manual workaround for now would be to boot with "iommu.forcedac=1"
> and hope that no other devices break because of it.

Thanks,
John

\
 
 \ /
  Last update: 2023-06-15 12:11    [W:0.103 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site