lkml.org 
[lkml]   [2020]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2020-06-11 16:12    [W:1.703 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site