From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Fri, 28 Sep 2012 11:31:10 +0100 Subject: [PATCH] ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() In-Reply-To: <20120928095808.GB18125@mudshark.cambridge.arm.com> References: <20120928095808.GB18125@mudshark.cambridge.arm.com> Message-ID: <20120928103109.GD7916@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > > > > 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 > > 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.