I guess the sparc64 glibc doesn't have this problem?
It does, but the issues I was referring to directly are contained
entirely within the kernel's realm of control.
And actually the glibc problem is not as bad as imagined. After the
first block or task switch (on sparc64 this is) the fpu is never
active again for that task unless it actually does fpu operations.
This is not the case most of the time on Intel because of the lazy fpu
state saving, which is the optimization what is effectively nullified
due to what glibc is doing.
And actually on sparc64 due to the fpu register dirty bits the chip
has, the glibc startup problem only results in one or two stores per
process (glibc at startup sets the fpu control word to a default
value). We don't do lazy state saving and always have the fpu save
area already allocated for every task.
And for us this makes a lot of sense, since userland is using VIS (and
thus the FPU) potentially for every memcpy/bzero etc. call in
userspace on the Ultra.
As a nice side effect, on sparc64 our fpu state saving is precisely
the same on both SMP and non-SMP. Whereas on sparc32 and Intel, the
lazy saving is only done on non-SMP, so there are two pieces of code
implementing the same thing in two different ways.
A final bit of administrivia about all this. I think Ingo doesn't
know what he has coming when he tries to do the csum_copy() MMX stuff,
which can touch userspace. Here is where the explicit "use FPU in the
kernel" support is going to be needed. The problem is, if you block
while using the FPU (page fault that needs to go to disk from
accessing user space), where do you save the FPU state? ;-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu