i don’t see anything crazy…
The last time I worked on this was mid-January, and I had been struggling for months. Now that I’m coming back to it, it appears to be working acceptably. I don’t know what changed, but this tells me that it’s at least possible to get acceptable performance with Trixie+v6.1.157-bone-rt-r43. The overall size of my image changed, so I’m wondering if my script that builds everything pulled in some changes made by the community to Trixie or the kernel.
I’ll investigate some more and let you know what I figure out.
Thanks!
Here’s a comparison of Jessie and Trixie performing the same task. Our application (lingui) and the PRU interrupts have about double the CPU usage on Trixie compared to Jessie. Also, the CPU usage of thttpd should be near 0% on both, but uses between 5% to 15% on Trixie. It gets worse when I attempt to read a large file from a USB drive, where the usb interrupts add another 30%. When the total CPU usage approaches 80+%, things stop working correctly.
Jessie:
Trixie:
I’m going to try to manage the total CPU usage by not generating PRU interrupts while reading large files over USB. I’m also going to try to reduce the rate of PRU interrupts. However, I would like to understand what changed in the Kernel/File system to cause the CPU usage to increase. Lingui is a real-time, multi-threaded application, if that makes a difference.
Any thoughts?
Just for knowledge sake, we are talking about 10 years of development between Debian Jessie (8.x) and Debian Trixie (13.x)… That’s a ton of changes to analyze.
Regards,
If it helps, I had the same issue with Bullseye and the 5.10 kernel, before you updated the tutorial. I know that’s still a big gap.
I don’t think anything in my application (lingui) could cause the CPU usage of the PRU interrupt (irq/55-pr+) to go up, assuming the interrupts are happening at the same frequency. The new version of top on Trixie will tell me the CPU usage of each thread of lingui. The older version of top on Jessie won’t, but by commenting out a few non-essential threads, it appears that the CPU usage has increased on all of threads. I don’t think it’s isolated to one thread.
I need to come up with a simple example program that will demonstrate the issue when ran on the different distributions. I’ll work on that.
On a different subject, is there a way to specify in the .conf for omap-image-builder to install openssh-server from trixie-backports instead of the standard repository?
with all this post quantium stuff, might make sense to backport it by default…
But otherwise, i need to make a few tweaks to allow that feature..
On the subject of security. Have you heard about this “Copy Fail” (CVE-2026-31431) vulnerability? Is someone working on a patch? IT department is asking about it.
see: https://www.cve.org/CVERecord?id=CVE-2026-31431
affected
affected at 4.14
unaffected
unaffected from 0 before 4.14
unaffected from 5.10.254 through 5.10.*
unaffected from 5.15.204 through 5.15.*
unaffected from 6.1.170 through 6.1.*
unaffected from 6.6.137 through 6.6.*
unaffected from 6.12.85 through 6.12.*
unaffected from 6.18.22 through 6.18.*
unaffected from 6.19.12 through 6.19.*
unaffected from 7.0
So what major are you using?
Regards,
6.1.157-bone-rt-r4
So I just need to get to or above 6.1.170?
lets see my ‘rt’ branch of 6.6 is 6.6.133-bone-rt-r42 and my ‘rt’ branch of 6.1 is 6.1.167-bone-rt-r47 so i need to update both of those… and 6.12.x-rt is is 6.12.79
fixed:
6.12.x-rt: GitHub - RobertCNelson/bb-kernel at am33x-rt-v6.12 · GitHub
6.6.x-rt: GitHub - RobertCNelson/bb-kernel at am33x-rt-v6.6 · GitHub
6.1.x-rt: GitHub - RobertCNelson/bb-kernel at am33x-rt-v6.1 · GitHub
5.15.x-rt: GitHub - RobertCNelson/bb-kernel at am33x-rt-v5.15 · GitHub
Thanks! I’ll upgrade to 6.1.170-bone-rt-48 soon.
Back to the performance issue. I have more data, but probably not enough to solve the mystery.
Under the same conditions, the CPU usage of the sendcol thread went from 11% under Jessie to 21% under Trixie. Almost double. Similarly, the pru interrupt went from 11% to 19%, and the BTNs_LEDs thread went from 6% to 11%. The BTNs_LEDs thread scans a 4x4 matrix of LEDs and buttons and is gpio intensive, while the sendcol thread processes the interrupts coming from the pru an is NOT gpio intensive. PrimaryIO, which sends and receives UDP packets, has also doubled.
Jessie:
Trixie:
I should also mention that the bootup time has more than doubled, but that might not be related.
Lingui’s main thread has NOT doubled, it is running a Qt 4.8 based GUI.