From: John Ogness <john.ogness@linutronix.de>
To: Florian Paul Schmidt <mista.tapas@gmx.net>,
Leon Woestenberg <leon@sidebranch.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Raspberry Pi 5 and PREEMPT_RT (6.13.0-rc3)
Date: Mon, 13 Jan 2025 12:15:05 +0106 [thread overview]
Message-ID: <84ikqjdl7y.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <1ae1d4d7-4e16-4c9e-b432-5769a816375b@gmx.net>
On 2025-01-13, Florian Paul Schmidt <mista.tapas@gmx.net> wrote:
>>> T: 0 (139313) P:95 I:1000 C: 5881 Min: 2 Act: 3 Avg: 3 Max: 10
>>> T: 1 (139314) P:95 I:1500 C: 3920 Min: 1 Act: 1 Avg: 7 Max: 419
>>> T: 2 (139315) P:95 I:2000 C: 2940 Min: 1 Act: 1 Avg: 7 Max: 480
>>> T: 3 (139316) P:95 I:2500 C: 2352 Min: 1 Act: 1 Avg: 9 Max: 433
>
>> I assume you see the same effect when running stress(1) pinned to CPU1?
>> ... just to be sure the boot CPU is not somehow special. (No need to
>> boot with isolcpus since the machine is otherwise idle anyway.)
>>
>> taskset 0x2 stress -m 1 --vm-stride 16 --vm-bytes 512000000 --vm-keep -c 1
>>
>> sudo cyclictest -m -p 95 -a 1,2,3 -t 3
>
> Yeah, I see the same behaviour with this way of running the test: The
> core with the stressor on it shows small latencies and the other huge
> ones. The effect disappears once I run two or more stressors, e.g.
>
> taskset 0x4 stress -m 1 --vm-stride 16 --vm-bytes 512000000 --vm-keep -c 1
>
> and
>
> taskset 0x8 stress -m 1 --vm-stride 16 --vm-bytes 512000000 --vm-keep -c 1
>
> Then all cores show huge latencies.
To me this looks like memory bus contention. I would expect you could
reproduce the same behavior with bare metal software.
Someone with some experience with this platform would need to speak
up. The usefulness of my casual responses has come to an end. ;-)
John Ogness
next prev parent reply other threads:[~2025-01-13 11:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 13:18 Raspberry Pi 5 and PREEMPT_RT (6.13.0-rc3) Florian Paul Schmidt
2024-12-20 14:05 ` John Ogness
2024-12-20 15:57 ` Florian Paul Schmidt
2024-12-22 10:32 ` Leon Woestenberg
2025-01-08 9:42 ` Florian Paul Schmidt
2025-01-12 15:14 ` Florian Paul Schmidt
2025-01-12 21:30 ` John Ogness
2025-01-13 9:15 ` Florian Paul Schmidt
2025-01-13 10:28 ` Florian Paul Schmidt
2025-01-13 11:09 ` John Ogness [this message]
2025-01-13 12:56 ` Florian Paul Schmidt
2025-01-14 10:28 ` Mike Galbraith
2025-02-14 8:31 ` Florian Paul Schmidt
2025-02-14 9:05 ` Mike Galbraith
2025-02-14 12:40 ` gene heskett
2025-02-14 12:06 ` Gabriele Monaco
2025-01-09 8:39 ` Florian Paul Schmidt
2025-01-07 14:39 ` Sebastian Andrzej Siewior
2025-01-08 9:48 ` Florian Paul Schmidt
2025-01-28 12:30 ` Tim Sander
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=84ikqjdl7y.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=leon@sidebranch.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=mista.tapas@gmx.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