On Sep 28, 2005, at 03:02, G?rard Gu?vel wrote: > > Andy, > > >> Your driver runs in kernel space. The kernel has the SPE bit off. >> The MSR state is process-specific. If the code executes, the >> MSR bit >> is set. Why do you want to see if the bit is set? >> > > OK, this is a bad idea to use a driver to check the msr register. > > I don't especially want to see if the bit is set, I just want > to improve the board performance for a Linux application :-). > > To check the performance, I used the Dhrystone 2.1 benchmark with > the standard glibc (strcpy, strcmp, ...) on one part, and with > the freescale SPE library on the other part (vstrcpy, vstrcmp, ...). > > I already verified in the binary elf file that the right functions are > called. > When I run the benchmark, I get the same MIPS with and without SPE > code.
Hmm... This is very strange, because Dhrystone is exactly the benchmark this was tested on. How did you determine that the SPE functions are called? > I ran the same benchmark on the same board without OS, > with a personal pseudo glibc, I have the same MIPS as under Linux, > with the freescale library, I gain 40% of perf. > > That's I want to retreive with the Linux OS. I'm not sure why you aren't seeing a performance gain, but I assure you that, if SPE instructions weren't working, Dhrystone would crash. The only other possibility I can think of is that the SPE versions of the functions aren't being called.
