Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset

[Arnd Bergmann]

On Mon, Jan 27, 2025, at 15:11, Julian Vetter wrote:
> On 1/27/25 11:27, Arnd Bergmann wrote:
>> On Mon, Jan 27, 2025, at 11:04, Julian Vetter wrote:
>
> Thank you for your quick reply. You're right, I was just going with the
> naming used in the powerpc arch which has an io_sync define. I'm now
> wondering if we can't simply use the read{l,q}/write{l,q} functions
> (instead of the __raw_xxx version), there are already calls to __io_br
> before and__io_ar after each read (and write). But this might have
> performance implications on some architectures, depending what it
> resolves to.
>
> Otherwise I propose renaming the __pre_io_sync and __post_io_sync into a
> single __io_mbr which is called before and after each loop. Looking at 
> PowerPC and SuperH, both of them could be consolidated into the generic 
> IO memcpy code when adding this. What do you think?

Having barriers between the accesses would be very expensive, and
prevent the write-combining and prefetching that can otherwise happen
(depending on mapping flags).

I suspect that the powerpc variant got this wrong for historic
reasons, but that's hard to tell now. The ppc32 variant didn't
have barriers at all originally, it was just memcpy/memset
before it got combined with ppc64 into arch/powerpc.

> The existing ones, especially __io_br unfortunately don't resolve to the 
> right define on these architectures. The __io_ar and __io_br resolve to 
> the right mb() on SuperH and PowerPC as well, but this would again have 
> implications on other architectures.

The barriers in the sh functions seem arbitrary, and I would
expect them to be wrong.


      ARnd