Messages in this thread | | | Date | Thu, 11 Jun 2020 15:11:02 +0100 | From | Catalin Marinas <> | Subject | Re: [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside kernel |
| |
On Thu, Jun 11, 2020 at 06:42:12PM +0900, Wooyeon Kim wrote: > I am in charge of camera driver development in Samsung S.LSI division. > > In order to guarantee real time processing such as Camera 3A algorithm in > current or ongoing projects, prebuilt binary is loaded and used in kernel > space, rather than user space.
Thanks for the additional details.
If you do such intensive processing in an IRQ context you'd probably introduce additional IRQ latency. Wouldn't offloading such work to a real-time (user) thread help? In a non-preempt-rt kernel, I don't think you can get much in terms of (soft) guarantees for IRQ latency anyway.
> Because the binary is built with other standard library which could use > FPSIMD register, kernel API should keep the original FPSIMD state for other > user tasks.
Can you not recompile those libraries not to use FP?
As Mark said, for a kernel API we require at least an in-kernel, upstreamed, user of that functionality.
> In the case of the kernel_neon_begin / kernel_neon_end that you mentioned, > there is a limitation that cannot be used in hardirq context. > Also, if another kernel task switching occurs while kernel API is being > used, fpsimd register corruption may occur.
kernel_neon_begin/end disable preemption, so you can't have a task switch (you can have interrupts though but we don't allow FPSIMD in IRQ context).
-- Catalin
| |