On Wed, Apr 20, 2011 at 2:48 PM, Arnd Bergmann arnd@arndb.de wrote:

Hi Tixy,

In general, you cannot use any FP code in the kernel, and there are few exceptions to that. I'm not sure about Neon here, but in general, you have to save the FP registers of the user process and enable the FPU using kernel_fpu_begin() or enable_kernel_fp() and release the FPU context using kernel_fpu_end() or disable_kernel_fp() depending on the architecture, before returning to user space.

NEON shares the register set used by VFP, so yes -- the same arguments apply.

I could not find these functions for ARM, maybe they have yet another name. If they don't exist, you might have to add them. In either way, saving the FPU state is generally expensive, so it's worth it only if we use many FP operations at once.

You're right; ARM doesn't currently have these so far as I can tell -- this is a possible area of investigation for linaro. Although we don't want to see sporadic FP operations dotted around the kernel, it may be worth saving/restoring the registers for specific bulk integer processing operations which we could using NEON, such as packet checksums, CRCs and crypto operations for example. It's hard to quantify the advantages (if any) without doing some investigation and benchmarking, though.

However, the benefit of allowing kprobes to be set in such code may still not merit the effort. We can revisit it later if it looks important.

Cheers ---Dave

On Wed, Apr 20, 2011 at 3:08 PM, Arnd Bergmann arnd@arndb.de wrote:

On Wednesday 20 April 2011, Dave Martin wrote:

...

You're right; ARM doesn't currently have these so far as I can tell -- this is a possible area of investigation for linaro.  Although we don't want to see sporadic FP operations dotted around the kernel, it may be worth saving/restoring the registers for specific bulk integer processing operations which we could using NEON, such as packet checksums, CRCs and crypto operations for example.  It's hard to quantify the advantages (if any) without doing some investigation and benchmarking, though.

However, the benefit of allowing kprobes to be set in such code may still not merit the effort.  We can revisit it later if it looks important.

I don't think it's likely to be worthwhile for packet checksums, since network packets are usually short. Anything related to block devices might be a better candidate.

That's useful to know -- I guess people have already looked into this possibility on other arches.

Is it possible to write an efficient AES implementation in NEON? We investigated using AltiVec on powerpc for AES before, where it turned out to be not worth it. Using Altivec was much faster than 64 bit integer operations, but the benefit was smaller than the overhead of enabling the unit and saving all the registers.

Possibly -- someone would need to look into it. NEON has some features which are useful for this kind of algorithm, but the devil's in the detail.

Cheers ---Dave