Here is the overview:
On a single processor with SMP=1, you get full lazy restore
and lazy saving.
On a real multiprocessor machine, the FPU state is saved
whenever there is a context switch from a process that used the FPU
during its run period, but restore is lazy. I.e.: if no other
process has used the FPU, since the last time the floating point
process has run *and* that process has not executed floating point
code on another CPU in the interim, then the FP restore is skipped.
Presumably, this should be the common case for FP programs.
By the way, it will not matter if the program executes some
integer-only code while on another CPU in the interim.
The code does have a spin lock for invalidating the loaded
FPU registers on other CPU's when a thread is destroyed, but
it only uses that lock in two places. Everywhere else, I believe
that the code can safely make the changes to the variables protected
by those locks without actually obtaining those locks. This is
because everywhere else the processor is only setting its own
version of this variable (one per procoessor) to NULL, and
the only time when one processor writes to another processor's
version of this variable is to set it to NULL too.
I have also put all of the per-CPU data into a data structure
that is larger than a CPU cache line, so there should be little
cache coherency contention over this stuff.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu