RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers
From: Finn Thain
Date: Thu Feb 25 2021 - 02:10:23 EST
On 2021年2月24日, Song Bao Hua (Barry Song) wrote:
>
>
Realtime requirement is definitely a true requirement on ARM Linux.
>
>
I once talked/worked with some guys who were using ARM for realtime
>
system.
>
The feasible approaches include:
>
1. Dual OS(RTOS + Linux): e.g. QNX+Linux XENOMAI+Linux L4+Linux
>
2. preempt-rt
>
Which is continuously maintained like:
>
https://lore.kernel.org/lkml/20210218201041.65fknr7bdplwqbez@xxxxxxxxxxxxx/
>
3. bootargs isolcpus=
>
to isolate a cpu for a specific realtime task or interrupt
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/isolating_cpus_using_tuned-profiles-realtime
>
4. ARM FIQ which has separate fiq API, an example in fsl sound:
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/fsl/imx-pcm-fiq.c
>
5. Let one core invisible to Linux
>
Running non-os system and rtos on the core
>
Regarding Linux systems, it appears that approach 3 could theoretically
achieve minimal interrupt latency for a given device without requiring any
interrupt nesting. But the price is one CPU core which is not going to
work on a uniprocessor system.
>
Honestly, I've never seen anyone who depends on irq priority to support
>
realtime in ARM Linux though ARM's RTOS-es use it quite commonly.
>
Perhaps you don't work with uniprocessor ARM Linux systems?
>
Once preempt_rt is enabled, those who want a fast irq environment need a
>
no_thread flag, or need to set its irq thread to higher sched_fifo/rr
>
priority.
>
Thanks for the tip.
>
[...]
>
>
Anyway, the debate is long enough, let's move to some more important
>
things. I appreciate that you shared a lot of knowledge of m68k.
>
No problem.
>
Thanks
>
Barry
>