crypto: arm64 - disable NEON across scatterwalk API calls
Get series with b4
b4 am 20171202135407.GU3326@worktopVersions newest first
- v1 Latest0 of 5 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls
Quoted 12 lines · Ard Biesheuvel
Quoted 9 lines · Ard Biesheuvel
They consume the entire input in a single go, yes. But making it more granular than that is going to hurt performance, unless we introduce some kind of
kernel_neon_yield(), which does a end+begin but only if the task is being scheduled out.For example, the SHA256 keeps 256 bytes of round constants in NEON registers, and reloading those from memory for each 64 byte block of input is going to be noticeable. The same applies to the AES code (although the numbers are slightly different)
Quoted 5 lines
Something like below should do the trick I think (apologies for the patch soup). I.e., check
TIF_NEED_RESCHEDat a point where only very few NEON registers are live, and preserve/restore the live registers across calls tokernel_neon_end+kernel_neon_begin. Would that work for RT?
Probably yes. The important point is that preempt latencies (and thus by extension NEON regions) are bounded and preferably small.
Unbounded stuff (like depends on the amount of data fed) are a complete no-no for RT since then you cannot make predictions on how long things will take.