David Daney wrote:
On 06/11/2010 07:32 AM, Manuel Lauss wrote:
Hi,
On Fri, Jun 11, 2010 at 4:06 PM, Jabir M<Jabir_M@xxxxxxxxxxxxxx> wrote:
I am working on a FPU-less 34k MIPS platform with linux-2.6.24
kernel. After running a Darwin media streaming server on the board
for a while, my oprofile results shows high utilization on
fpu_emulator_cop1Handler()& r4k_wait().
r4k_wait() is the idle task, so that indicates there is nothing to do
at those sample points.
Which suggests that the system is either waiting on I/O data, or
crunching it using a lot of floating point computation. Normally, a
high level of idle would indicate that the system is easily keeping up
with the data stream, but if you're running the 34K as one of the
available flavors of virtual SMP, you may be seeing a lot of wait loop
samples because there's only one runnable thread in the job mix.
wiki page http://www.linux-mips.org/wiki/Floating_point says gcc will
use hard float as default and soft float is best suited model for a
fpu less processor. Could anyone kindly help me in understanding use
of -msoft-float .
Whether I need to compile
1. kernel with -msoft-float ? or
The kernel doesn't use floating point. So it doesn't matter.
It makes no sense to build the kernel -msoft-float, but it should be
noted that there are a couple potential places (e.g. ptrace /proc) where
the difference in user-mode floating point argument passing ABIs is
kernel-visible.
2. Glibc ? or
3. Application ? or
4. All the above ?
If you don't want to use the kernel's FP emulator, you need 2 and 3.
I have fought with this in the past; what you need to do is:
- build gcc with softfloat support (mipsel-softfloat-linux-gnu triplet
for example),
- build a libc with this new compiler,
- then rebuild all libraries and apps with you new softfloat toolchain.
Let me be a bit more clear on this. Because of the ABI difference, you
need to either rebuild your application as a static binary, with the
main program and *all* constituent libraries likewise rebuilt with
softfloat, or, if you absolutely need it to be dynamically linked, you
need to rebuild the shared libraries and *all* programs that might use
them, which means essentailly a full userland rebuild.
An optimized, assembly-language soft-float library implementation is
*much* faster than the kernel emulator, but I benchmarked it once upon a
time against a portable gnu soft-float library in C, and the difference
wasn't nearly as dramatic.
Regards,
Kevin K.
