Re: [PATCH 04/11] dma-direct: clean up the remapping checks in dma_direct_alloc

[Robin Murphy <robin.murphy@arm.com>]

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
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu