Re: [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside kernel

[Catalin Marinas]

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