Pi zero with Raspbian shows 28% constant CPU usage?

[ProDigit]

I see a constant 28% CPU usage in the CPU usage monitor applet on the taskbar.
Before it would hover between 0 and 2% when inactive.
Probably on a stock (non-overclocked Pi Zero, it might show closer to 30% CPU usage).

I tried taskmanager (CTRL + ALT + DEL, or lxtask), or htop, even tried sudo lxtask or sudo htop, but can't seem to find the service that's using the ~28% CPU usage.
Htop or lxtask themselves use about 5% on the Zero W, and Xterminal uses 1-2%.
The rest of the services show 0%.

TOP on the other hand, shows a service called 'kworker/0:1+events' that's using 6.9% of CPU load, that the other two don't show.
There's another 'kworker/0:0+events' in memory as well, using up to 5.2% of CPU.

I can't seem to kill the service, it seems to remain remnant.

What do I do?

The only other article I read, this one, mentioned about increasing the VRAM, which I did (to 48MB, which should be plenty for a 480pixel screen), but without success.. I still have the odd CPU usage.

[neilgl]

What devices have you attached to that .pi zero if any - 480 pixel screen sounds unusual?
And are you running any containers?

[ProDigit]

It's a 480x320p screen, running at 720*480p resolution (hardware scaled), for compatibility with my external HDMI monitor (when needed).

No containers

I removed the overclocking options, rebooted, and still the same.
I saw I forgot to remove the over_voltage settings; it was running stock speeds at over_voltage=5 before.
After reboot, the CPU usage disappeared.

I then proceeded to overclock the GPU again, and set over_voltage back to 5, and I now saw a 10% CPU usage.
I then set the over_voltage=3, and rebooted, and idle CPU usage hovered between 6-11%.
Is there a corelation to overvoltage, and the misreading of CPU usage?

It's working kind of erratic. When I increased the core frequency, CPU usage went up again.

*edit: I reduced the over_voltage to zero, and the CPU usage dropped to 10%.
I now see a lot of 'kworker' services active (like 5?)

[DirkS]

How is the screen connected? HDMI?

[ProDigit]

How is the screen connected? HDMI?

GPIO hat.
I checked this thread, but the wifi doesn't seem to be the cause...

I tried

Code: Select all

sudo -s
echo 1 > /proc/sysrq-trigger

without success... Nothing displays.

Update: I set

Code: Select all

core_freq=500

, and CPU usage went back to 28%. This with over_voltage set to 3.

I tried modifying the sdram_freq to 550, and the idle CPU usage increased again.
It seems to be related to overclocking. Though before I never saw this kind of behavior.

..Still testing what's going on...

[Paeryn]

kworker threads are threads that process the kernel's workqueues. The first number says which CPU it's running on (so always 0 on an RPi 0), the second is it's id number and the string at the end is I think related to what the thread is for (so events would be something to do with monitoring events). You can't kill them, they belong to the kernel.

It's possible to get a trace of what the kworker threads are running, how much help it'll be depends, but you can get it by doing this (you'll have to press ^C (CTRL-C) after a second or so to stop the cat otherwise it will go on forever. The first line enables tracing, the second captures a snapshot of what is happening and the third disables the tracing (you don't want to leave it on any longer than needed).

Code: Select all

pi@rpi3:~ $ echo 1 | sudo tee /sys/kernel/debug/tracing/events/workqueue/enable
pi@rpi3:~ $ sudo cat /sys/kernel/debug/tracing/trace_pipe >workqueues.txt
^C
pi@rpi3:~ $ echo 0 | sudo tee /sys/kernel/debug/tracing/events/workqueue/enable

You can then look at the file workqueues.txt to see what each was doing. The kworker names have their process number after them (e.g. kworker/0:0-7839 rather than kworker/3:0-events) so you'll have to use ps or top to get the process number for the kworker thread you are concerned by).

[ProDigit]

After debug there is no folders
The /tracing/... folder it doesn't accept

Gets output 0


Another strange thing I've noticed is that the zero crashes at sdram_freq=575 and sdram_over_voltage=1,
but succeeds to boot and operate at sd_freq=600 with sdram_over_voltage=1.
Not sure if this is related.

The biggest changes I see is when core_freq is overclocked. It goes almost linear from 10% CPU usage at stock 400Mhz, to 36% CPU usage at 600Mhz.

It shows glxgears shows:
~7.63 fps at stock core_freq of 400
~7fps @ 450Mhz
~7.1fps @ 500Mhz
~7.1fps @550Mhz
~7.1fps @600Mhz

Seems like the increase in core frequency, directly related to the increase in CPU frequency, causes FPS in GLXgears to remain the same.

I bumped against another bug,
It appears that enabling force_turbo with these overclocking settings, the bootloader crashes. (Colored window has black tiny blocks on it).
However without turbo on, these overclocking settings pass most CPU and IO stress tests, as well as GLXGears.


I notice I get a lot of inconsistent overclocking errors..
Perhaps something in the hardware is broken.

[Paeryn]

After debug there is no folders
The /tracing/... folder it doesn't accept

You can't access that directory as a normal user, only root can. It probably needs the kernel compiled with tracing enabled, I tested it on mine running Buster and it worked, I don't know if previous versions had it enabled in the kernel, maybe not.

I notice I get a lot of inconsistent overclocking errors..
Perhaps something in the hardware is broken.

Do you get errors when not overclocking? Things aren't guaranteed to work when overclocking, you're pushing the chips past what they are rated to work at.

[ProDigit]

After debug there is no folders
The /tracing/... folder it doesn't accept

You can't access that directory as a normal user, only root can. It probably needs the kernel compiled with tracing enabled, I tested it on mine running Buster and it worked, I don't know if previous versions had it enabled in the kernel, maybe not.

I notice I get a lot of inconsistent overclocking errors..
Perhaps something in the hardware is broken.

Do you get errors when not overclocking? Things aren't guaranteed to work when overclocking, you're pushing the chips past what they are rated to work at.

No,I mean,
Ram operates fine at 400 and 600Mhz, but crashes at 575Mhz. Same with GPU, runs fine at 525Mhz and 550Mhz, but crashes at 533Mhz.
System overclocked works fine, I then decide to increase one value, say Arm_freq. After reboot the settings don't work, so I set the setting back to last known working configuration, yet it doesn't boot.

System instability noticed at over_volt=3, so I change to over_volt=5. On another overclocking run from stock, I end up with exactly the same overclocking settings, but working at over_volt=1.

I've been at it for 2 days now (several hours), to find a stable overclock, and always end up with previous results are invalidated.

The Pi3B+ overclocked in a matter of a few hours. This one.... I don't know.

[Paeryn]

No,I mean,
Ram operates fine at 400 and 600Mhz, but crashes at 575Mhz. Same with GPU, runs fine at 525Mhz and 550Mhz, but crashes at 533Mhz.
System overclocked works fine, I then decide to increase one value, say Arm_freq. After reboot the settings don't work, so I set the setting back to last known working configuration, yet it doesn't boot.

System instability noticed at over_volt=3, so I change to over_volt=5. On another overclocking run from stock, I end up with exactly the same overclocking settings, but working at over_volt=1.

I've been at it for 2 days now (several hours), to find a stable overclock, and always end up with previous results are invalidated.

The Pi3B+ overclocked in a matter of a few hours. This one.... I don't know.

You say the RAM fails at 575 but works fine at 600, how sure are you that it was fine at 600? It could be that there were problems running at that speed but in locations where it wasn't evident or just hadn't happened in the time you tested it.

Was your issue of a kworker thread eating CPU time happening when overclocked, and does/did it happen when not overclocked? If it only happens when overclocked that could be a sign that the overclocking isn't stable.

[ProDigit]

Yes, CPU usage increases as the overclock increases.
CPU, GPU, and sdram overclock are responsible for up to 10% of CPU usage. The higher the overclock, the higher the CPU usage.
At 10% CPU usage, with
arm_freq=1050
gpu_freq=550
sdram_freq=600

I get best overclocking results, stable in my tests, but 10% CPU usage.

Add core_freq=550 to 600 to the mix, and constant CPU usage is 28+35%, and performance goes actually down.
core_freq seems to be responsible for 15-20% of CPU idle usage, even when using it just by itself.
I haven't had the pi zero W long enough, to know if this behavior was always present, or only recently.

Any value of +20 above 600 (or 550 for GPU) will crash during tests, so I consider it unstable. It has at least 20Mhz extra overclocking room.

Do these overclocking values look ok for a stock pi zero W, with no cooling?
The CPU temp sensor indicates with these values, the CPU doesn't exceed 51-54C.

Aside from the above overclocking settings, which I've been able to do with over_voltag=1, setting a higher value in over_voltage, will only result in even higher idle CPU usage.

I did notice that 'force_turbo=1' now doesn't boot the pi anymore, like it did when I changed settings to 'over_voltage=5' on CPU/GPU and sdram.