On 2021-12-07 11:49, Christoph Hellwig wrote:
On Mon, Dec 06, 2021 at 04:33:10PM +0000, Robin Murphy wrote:
On 2021-11-11 06:50, Christoph Hellwig wrote:
Add two local variables to track if we want to remap the returned
address using vmap or call dma_set_uncached and use that to simplify
the code flow.
I still wonder about the asymmetry between the remap and set_uncached cases
WRT the memset(), which stands out even more the further we clean things
up, but that's another matter.
The memset for the remap case obviously needs to be done after
remapping.
For highmem and certain encryption setups, yes, but plain non-cacheable
remaps like on arm64 could technically be done either way round.
OTOH for the set_uncached case the memset is much faste
when done on the cached mapping, which must be done before calling
arch_dma_set_uncached.
Indeed the memset() itself will be faster, but a fair amount of that
"saving" will just be punting work to arch_dma_prep_coherent() -
ultimately the same number of bytes of zeros has to be pushed out into
the memory system either way. It should certainly be somewhat more
efficient in that any previously-dirty cache lines won't get written out
twice, and background cache eviction allows a bit more overlap of
operations, but I'm wondering how significant a difference it really is
in practice.
Really, though, I'm thinking ahead to the remap-in-place idea using
set_memory_*() or similar, and where that might fit into all this, as it
seems to be about equal parts remap, set_uncached, and neither.
Robin.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
