[intel-platform-discuss] Intel Platform optimised software crypto algorithms

[Bill Holler]

I will add kernel thread SSE support as part of the Intel
performance project.

Bill

Dan Mick wrote On 03/15/07 13:48,:
> 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
>>>>
>>>>
> 
> 
> _______________________________________________
> intel-platform-discuss mailing list
> intel-platform-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/intel-platform-discuss