public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Pavel Pisa <pisa@fel.cvut.cz>
Cc: linux-rt-users@vger.kernel.org, Carsten Emde <c.emde@osadl.org>,
	linux-can@vger.kernel.org,
	Oliver Hartkopp <socketcan@hartkopp.net>,
	Jan Altenberg <Jan.Altenberg@osadl.org>
Subject: Re: Question for AMD/Xilinx Zynq PREEMP_RT configuration check, CAN latency measuremet and FOSDEM 2025
Date: Wed, 29 Jan 2025 11:17:09 +0100	[thread overview]
Message-ID: <20250129101709.XQuo8Jle@linutronix.de> (raw)
In-Reply-To: <202501281629.27139.pisa@fel.cvut.cz>

On 2025-01-28 16:29:27 [+0100], Pavel Pisa wrote:
> Please check if you find some problematic choices.

I didn't find anything obviously wrong. Assuming your CPU is busy in
general you could remove NO_HZ in favour of PERIODIC. This is however
not to cause spikes you describe below.

> The cyclic test worked well, and we have even delivered two systems
> to OSADL QA real-time farm 
> 
>   https://www.osadl.org/?id=4109

It shows "IRQ work interrupts". Not sure what causes them.

> However, the CAN/CAN FD communication latency measured on the CTU CAN FD IP
> core is far from optimal. Some runs under load with
> 10 msec latency. Our own CAN FD stack for RTEMS keeps with no exception
> under 60 usec on the same hardware.
> 
> I understand that the Linux socket layer and networking
> stack are complex, and many optimizations are ahead.
> We will be happy to contribute where we can and find time
> and even some resources to engage more students etc...
> 
> But I would like to be sure that the bad results are not
> caused by our mistakes in configuration.

You have CAN and "regular networking". My guess would be that regular
networking blocks blocks BH and so your CAN. You could try to have all
interrupts serviced on CPU0 and move CAN to CPU1. If so this should
improve then. Other than that, I would suggest to get some tracing to
see what delays your CAN interrupts and/ or handling in general. 

> I will be happy to meet you and discuss Linux and other
> control and real-time areas at FOSDEM 2025.

I should be able to make it.

…
> Slides in English which I want to update/correct for FOSDEM
> 
>   https://talks.openalt.cz/media/openalt-2024/submissions/3XTMDF/resources/openalt24_linux_for_rt-reduced_FbZPuS0.pdf

looks good. If you want additional history points, I have some at
	https://files.speakerdeck.com/presentations/0620b5b3a00b42fc91fba6cc4092d278/KR_2024_PREEMPT_RT_over_the_years.pdf
	Slide 11 - 21.

However you have most of the pieces so.

> Best wishes,
> 
>                 Pavel
> 

Sebastian

  reply	other threads:[~2025-01-29 10:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 15:29 Question for AMD/Xilinx Zynq PREEMP_RT configuration check, CAN latency measuremet and FOSDEM 2025 Pavel Pisa
2025-01-29 10:17 ` Sebastian Andrzej Siewior [this message]
2025-01-29 12:04   ` Pavel Pisa
2025-01-29 14:40     ` Sebastian Andrzej Siewior
2025-03-28 12:04     ` CAN latency measuremet on AMD/Xilinx Zynq with PREEMP_RT - added threaded NAPI configuration Pavel Pisa
2025-04-17  8:12       ` Sebastian Andrzej Siewior
2025-04-18 10:12         ` Pavel Pisa
2025-04-18 20:18           ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250129101709.XQuo8Jle@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=Jan.Altenberg@osadl.org \
    --cc=c.emde@osadl.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=pisa@fel.cvut.cz \
    --cc=socketcan@hartkopp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox