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-----