Yeah, basically, what Bill said. Nothing in the kernel tries to arbitrate among kernel users of FP-and-related state, so each subsystem that uses it uses it sparingly and with its own careful state management.
Michael Corcoran wrote: > Bill Holler's having problems sending to the alias and he has a much > more detailed reply: > >> Kernel threads do not save XMM state, so disabling preemption as >> this code does is necessary. This may not be ideal if algorithms >> that wants to store a lot of data in the 16 available 128-bit >> XMM registers for longer periods of time. >> >> There has been some discussion in the Intel project of adding >> XMM context save to kernel threads. Perhaps there could be >> a flag per kernel thread that specifies it is using XMM state, >> so only those threads would have their XMM context saved. >> There could also be policies regarding which priority levels >> could use the registers. I would like to do this as part of >> the Intel platform Performance project. >> >> What would *really* help get the above project (In Kernel >> XMM context) going is if we knew the need for this and had >> examples of algorithms that will use this feature. IIRC >> ZFS compression/encryption, crypto, and a sound driver would >> like to use XMM register context in kernel. We do not want >> to write these algorithms using SSE, but would like to enable >> others to. We are hoping to receive SSE2/SSE3 code examples >> from Intel or the open source community. Our initial >> request from Intel did not get far. >> >> If we don't form a community for this, everyone will end >> up doing it there own way.... >> >> Regards, >> Bill > > === end of Bill's reply > > On Thu, 2007-03-15 at 10:29 -0700, Michael Corcoran wrote: >> On Thu, 2007-03-15 at 17:00 +0000, Darren J Moffat wrote: >>> Sherry Moore wrote: >>>>> On Thu, Mar 15, 2007 at 01:48:53PM +0000, Darren J Moffat wrote: >>>>>> All the algorithms listed above are build for userland and kernel >>>>>> from the same algorithm source code but with slightly different >>>>>> "plumbing". >>>>> What are the restrictions on using (say) SSE instructions in the >>>>> kernel? >>>> There aren't any kernel specific restrictions. Just the general: the >>>> FPU has to be enabled, the processor has to support SSE. >>> So is this code we have in our bignum implementation not required ? >>> >> I don't know this for a fact, but I thought (fuzzy memory) we didn't >> save fp registers by default on a context switch/interrupt and thus if >> you didn't disable preemption, you'd run the risk of those registers >> getting corrupted. If we can guarantee that there will be no fp ops in >> an interrupt handler, then it probably doesn't make a difference if an >> interrupt occurs. For userland, I think we are smarter about saving off >> the fp registers if a program is using them. >> >> --Mike >> >>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/bignum/i386/bignum_i386_asm.s#110 >>> >>>
