[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <96385966-f423-4218-bd7-1bc7d8e6113f@telegraphics.com.au>
Date: Thu, 25 Feb 2021 18:07:22 +1100 (AEDT)
From: Finn Thain <fthain@...egraphics.com.au>
To: "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
cc: tanxiaofei <tanxiaofei@...wei.com>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxarm@...neuler.org" <linuxarm@...neuler.org>,
"linux-m68k@...r.kernel.org" <linux-m68k@...r.kernel.org>
Subject: RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization
for SCSI drivers
On Wed, 24 Feb 2021, 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@linutronix.de/
> 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
>
Powered by blists - more mailing lists