Re: Patch: cprng_fast performance - please review.
David Laight <[email protected]> Wed, 23 Apr 2014 22:50:13 +0100
| Newsgroups | gmane.os.netbsd.devel.crypto,gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Apr 18, 2014 at 02:41:07PM -0400, Thor Lancelot Simon wrote: > > Of the few systems which do have instructions that accellerate AES, on > the most common implementation -- x86 -- we cannot use the instructions > in question in the kernel because they use CPU state we do not save/ > restore when the kernel runs. I'd welcome anyone's work to fix that, > so long as it does not impose major performance costs of its own, but > I do not personally have the skill to do it, and if wishes were horses... On x86 the xmm registers could be used in kernel code provided that: 1) If the fpu registers are owned by a different process they are saved into the pcb (because an IPI might ask they be saved). (Or save the resister values somewhere the IPI can save them to the pcb from.) and: 2) Pre-emption is disabled. and: 3a) If the fpu registers are owned by the current process the registers used are saved and restored. or: 3b) If the fpu is not active it is enabled (and then disabled). You probably don't want to to a full fpu save unless you really need to. I'd guess that the AES instruction would only need a couple of xmm/ymm registers. There is one luring issue with the intel cpus though.... If the user program has used AVX encoded instructions that affect the ymm registers there is a big clock penalty for the first non-avx encoded instruction that uses the xmm ones (don't ask what the hw guys f*cked up and bodged a fix for...). The ABI requires that the ymm (high) registers be cleared with a special instruction before every function call - which will include all system calls, but this won't be true if the kernel is entered by an interrupt. I don't know about amd cpus. David -- David Laight: [email protected]