Accessing the preload engine from userspace

Henry Gomersall <[email protected]> Wed, 24 Feb 2016 14:19:49 +0000
Newsgroups gmane.linux.ports.arm.general
Message-ID <[email protected]>
I'm working on some performance critical numerical code running on a 667
MHz Cortex A9 (in a Xilinx Zynq) that is currently cache limited.
I can achieve ~1 neon multiply per memory access on small datasets (~530
MFlops), dropping to far less when the data size gets bigger (~180MFlops
in the limit).

The 180 MFlops figure above is with PLD instructions (which definitely
help), but I'm still nowhere near the theoretical memory bandwidth of
the main memory (DDR2 @533MHz). Given the problem is essentially
operating on sequential memory accesses that are fully defined a priori,
I was wondering if I could speed things up with the L2 preload engine.

Now, I've experimented somewhat with this, writing a small kernel driver
that flips the PLEUAR register bit to enable userspace access to the PLE
(as well as fiddling a bit with the PLEPCR register to reduce the cycles
between PLE operations), and then performing the PLE operation
(something like
"MCRR p15, 0, %[vect_addr], %[vect_config], c11;").

Various things are apparent from this:
1) The program runs successfully about 20% of the time, the remaining
times it yields an "Illegal instruction" almost immediately on the first
attempt to set up the PLE.
2) The run times are not affected in the slightest. If this is expected,
I'm very interested to know whether it's possible to ever operate on
data accessed at the memory bandwidth.
3) I can monitor the (16 length) FIFO and observe it decreasing in space
as the instructions are added and then reverting to empty.

My observations would suggest I'm not doing what I think I'm doing, or
at least, something is thwarting my attempts to do what I want to do.

Am I missing something fundamental here? Am I treading all over the
kernel's carefully protected space?

Are the virtual addresses different as viewed by the PLE compared to the
running process?

Why might the illegal instruction occur?

Any pointers or useful insights would be thankfully received.

Cheers,

Henry

_______________________________________________
linux-arm mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm
signature.asc (application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWzbwJAAoJEGf0MT1zztWm6TgP/3bdui0TrJe35UyeOQPU60/Z
/70uYlxJ6SrgpvFx5lx2xoKhkrCv1oit0kbn/sesoIm3O2hi6gxuALQcCnjX+F+2
9ib0f+quTVCnqw8ptyYKcIqDvAVn6SqM9NqLzuMi+66XIJd/YEVBO4JATQnnTkvN
tYz5olM6KZmdSYzIPsxMk5LaMVg5Ri33RPRKOxlsR8b54Y3PMkvR5SvkJsaaH0UL
+fxsEnNaqPnB6j3xFM18TUGs8fbUXFEtw6Va/bYO1EfgDWzSJb//FtK1mfPQgTtf
6aRIK78b7NkuAlYhsP1P09ksEnTGFFAW0bu0grak+AILpOSqckYofWwb1jL2f0AE
NANOhMgT1lI43JqEczq80x0vuCBTANyCpDCEPMSoJ1yqOK06T3zu3lFPKNjOk1WR
dfk7l8lFeMQpwEokKikZ2nlTT6xeWYavKrKJVIHOpG8gnM/JqCh+mmLIx2w7IN0k
e0kw9lJhb0w3H0l5mMUfgNlOCTBZYihl3qc4/lmRZo6NoDh+FG7nmx8SbaUhc56N
Nv6hjV+5qrT5jwo1UIi50I3dOJgd8nyyjdugB0D5X2eqqj8kczFwbSXNeoGU9Wiy
V35VHkfUs7I/TEWZ0RGGwSPUjlrpmp2Y7de9ZFnsUfnpDP+saEv9elQT8tdU1hCr
MNIFrUBmnM2TJ+4HMbip
=x496
-----END PGP SIGNATURE-----