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

From: Julian Vetter
Date: Tue Jan 28 2025 - 03:33:06 EST


On 1/27/25 16:48, Arnd Bergmann wrote:
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).

Yes, ok. I see.


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.


hmmm... ok. I'm not sure what do make of this. But maybe I can just send a patch to the PowerPC mailinglist, without those "sync" calls and see what they have to say.

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.

Ok, same for SuperH, I will send a patch to the mailinglist without the 'mb()' before and after and see what they say. If they don't like it, I will come back to this.

Julian


ARnd