[PATCH] ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio()

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Fri, Sep 28, 2012 at 10:58:08AM +0100, Will Deacon wrote:
> On Fri, Sep 28, 2012 at 05:17:53AM +0100, Nicolas Pitre wrote:
> > On Thu, 27 Sep 2012, Russell King wrote:
> > 
> > > If we are building for a LE platform, and we haven't overriden the
> > > MMIO ops, then we can optimize the mem*io operations using the
> > > standard string functions.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > We presume that the IO space is able to cope with a mixture of access 
> > width other than byte access which should be perfectly reasonable by 
> > default.  If so then...
> > 
> > Acked-by: Nicolas Pitre <nico@.linaro.org>
> 
> This looks pretty scary to me, but maybe I'm worrying too much. The first
> thing to ensure is that the accesses are always aligned, which I believe is
> true for the string operations. However, a quick glance at memset shows that
> we do things like store multiple with writeback addressing modes. This is
> bad for a few reasons:
> 
> 	1. If an access other the first one generated by the instruction
> 	   causes an abort, the CPU will ultimately re-execute the earlier
> 	   accesses, which could be problematic to a device.

I don't think that's a problem for these.  They're used on RAM like
regions.

> 	2. Writeback addressing modes when accessing MMIO peripherals causes
> 	   serious performance problems with virtualisation, as I have
> 	   described before.

Well, virtualisation is in its infancy on ARM, and I don't think should
be worried about _too_ much when these operations are grossly unoptimized
for non-virtualised hardware.  The tradeoff is between grossly unoptimized
on non-virtualised hardware vs performance problems with virtualised
hardware.

> 	3. We have to guarantee that no single instruction causes accesses
> 	   that span a page boundary, as this leads to UNPREDICTABLE
> 	   behaviour.

We do accesses in memset() 16-bytes at a time, so to guarantee that we
need to ensure that the pointer passed in was 16-byte aligned.  I'm not
sure that we can guarantee that in every case.

> So, unless we can guarantee that our accesses are all aligned, will never
> fault, do not cross a page boundary and we are not running as a guest then
> I'd be inclined to stick with byte-by-byte implementations for these
> functions.

Well, that rather sucks if you're memset_io'ing various sizes (in
megabytes - up to 8MB) of video memory.  We desperately need these
functions optimized.

Either that or we allow DRM to be a security hole by omitting any kind
of buffer clearing, because using the existing memset_io() is just far
too expensive to clear 8MB a byte at a time.