public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: mfranklin@comfiletech.com, linux-rt-users@vger.kernel.org
Subject: Re: i2c jitter is worse in PREEMPT_RT kernel than stock Raspberry Pi kernel
Date: Tue, 12 Dec 2023 13:42:08 +0100	[thread overview]
Message-ID: <da41b939c1f2bbc9735250301ba3c4e735dfb313.camel@gmx.de> (raw)
In-Reply-To: <44fb3d4d-6303-4287-b2ac-7898cc237c47@comfiletech.com>

On Tue, 2023-12-12 at 11:53 +0900, Michael Franklin wrote:
> Hello,

Greetings,


<snip proggy etc>


> Interestingly, in the stock kernel, `htop` shows that most CPU activity
> is concentrated on core 3 (which is what I expected and preferred),
> while in the realtime kernel, the CPU activity is distributed across all
> cores, despite booting with `isolcpus=3` and running the test program
> with `task set -cp 3 $(pidof i2ctest)` in both kernels.
>
> Q1:  Why is i2c communication is more jittery in the realtime kernel
> than the stock kernel?

I'd speculate it's primarily due to threaded IRQ handling being both
more expensive and preemptible.

> Q2:  Why is activity distributed across all cores in the realtime
> kernel, but more concentrated on core 3 in the stock kernel?

I don't see that.  Using isolcpus or not, the test proggy wakes only on
CPU3 (as it had damn well better), and box wide affinity i2c IRQ thread
wakes on CPU0.

Booting the non-rt kernel with 'threadirqs' behaves the same, and I
suspect will jitter about the same should you try it.  You're isolating
the test proggy, but for the rt kernel the IRQ thread is left dangling
in the breeze to be perturbed by other IRQ threads or whatnot.

	-Mike

  reply	other threads:[~2023-12-12 12:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12  2:53 i2c jitter is worse in PREEMPT_RT kernel than stock Raspberry Pi kernel Michael Franklin
2023-12-12 12:42 ` Mike Galbraith [this message]
2023-12-13  3:33   ` Michael Franklin
2023-12-13  4:37     ` Michael Franklin
2023-12-13  8:15     ` Mike Galbraith

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=da41b939c1f2bbc9735250301ba3c4e735dfb313.camel@gmx.de \
    --to=efault@gmx.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mfranklin@comfiletech.com \
    /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