Tool/software: Linux
Hi
I hope someone can help me identify why the performance of my processor gets affected when I am running a specific getty process.
I am running on a custom board based on the beagle bone black with a very cut down root filesystem that uses busybox for as much as possible (no systemd or udev)
I am probably due for updating my kernel (but at present aside from the present confusing behaviour it is working OK fo me)
root@am335x-evm:/dev# uname -a Linux am335x-evm 4.4.19-gdb0b54cdad #238 PREEMPT Fri Aug 25 16:25:18 AEST 2017 armv7l GNU/Linux
The process that is causing the performance hit is:
389 root 1964 S /sbin/getty 115200 ttyGS0
This is started via the following line in my inittab
us:12345:respawn:/sbin/getty 115200 ttyGS0
It is to provide access via the USB serial connection of a g_multi gadget; this is useful for debug purposes.
However if I do not open a connection to this on the host PC (e.g via minicom) it appears to hog the CPU.
I have confirmed this via writing a small app that tests the time to execute a tight loop; simply decrementing a counter.
With the getty process running (and no terminal connected from the host PC)
Executing 10 loops of 100000000 decrements 100000000 decrements in 1.576790 sec 100000000 decrements in 1.578677 sec 100000000 decrements in 1.577245 sec 100000000 decrements in 1.580821 sec 100000000 decrements in 1.566301 sec 100000000 decrements in 1.576454 sec 100000000 decrements in 1.737427 sec 100000000 decrements in 1.569567 sec 100000000 decrements in 1.569041 sec 100000000 decrements in 1.553326 sec
Without the getty process running
Executing 10 loops of 100000000 decrements 100000000 decrements in 0.668262 sec 100000000 decrements in 0.667599 sec 100000000 decrements in 0.667559 sec 100000000 decrements in 0.667849 sec 100000000 decrements in 0.669318 sec 100000000 decrements in 0.667540 sec 100000000 decrements in 0.667891 sec 100000000 decrements in 0.667541 sec 100000000 decrements in 0.668885 sec 100000000 decrements in 0.667562 sec
In each case top reports this test process as taking 99% of cpu.
Each decrement takes 4 operations so 2/3 of a second at a cpu frequency of 600000000Hz looks correct for 100000000 loops.
I have confirmed that this is not just the CPU frequency being changed
- there are no changes recorded in root@elle-board:/sys/devices/system/cpu/cpufreq/policy0/stats
- if I do change the frequency from 600000000 to 300000000 the time taken doubles e.g.
100000000 decrements in 1.335705 sec 100000000 decrements in 1.337115 sec 100000000 decrements in 1.336521 sec 100000000 decrements in 1.336904 sec
this is a distinctly different ratio from the slow down seen with the getty running.
There is very little else running on the system: ps reports:
root@elle-board:~/cm# ps
PID USER VSZ STAT COMMAND
1 root 1360 S init [5]
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [kworker/0:0]
5 root 0 SW< [kworker/0:0H]
6 root 0 SW [kworker/u2:0]
7 root 0 SW [rcu_preempt]
8 root 0 SW [rcu_sched]
9 root 0 SW [rcu_bh]
10 root 0 SW [kdevtmpfs]
11 root 0 SW< [netns]
12 root 0 SW< [perf]
13 root 0 SW [kworker/0:1]
14 root 0 SW< [writeback]
15 root 0 SW< [bioset]
16 root 0 SW< [kblockd]
17 root 0 SW< [edac-poller]
18 root 0 SW< [rpciod]
19 root 0 SW [kswapd0]
20 root 0 SW [fsnotify_mark]
21 root 0 SW< [nfsiod]
22 root 0 SW [kworker/u2:1]
27 root 0 SW< [dma_wq]
28 root 0 SW< [bioset]
29 root 0 SW< [bioset]
30 root 0 SW< [bioset]
31 root 0 SW< [bioset]
32 root 0 SW< [bioset]
33 root 0 SW< [bioset]
34 root 0 SW< [bioset]
35 root 0 SW< [bioset]
36 root 0 SW [spi1]
37 root 0 SW< [bioset]
38 root 0 SW< [bioset]
39 root 0 SW< [bioset]
40 root 0 SW< [bioset]
41 root 0 SW< [bioset]
42 root 0 SW< [bioset]
43 root 0 SW< [bioset]
44 root 0 SW< [kpsmoused]
45 root 0 SW [irq/76-rotary-e]
46 root 0 SW [irq/77-rotary-e]
47 root 0 SW [irq/140-4806000]
48 root 0 SW< [bioset]
49 root 0 SW [mmcqd/0]
50 root 0 SW< [ipv6_addrconf]
51 root 0 SW< [deferwq]
52 root 0 SW [kworker/u2:2]
53 root 0 SW [irq/162-44e0b00]
54 root 0 SW [irq/163-4802a00]
55 root 0 SW< [kworker/0:1H]
56 root 0 SW [jbd2/mmcblk0p2-]
57 root 0 SW< [ext4-rsv-conver]
338 root 0 SW [kworker/0:2]
343 root 0 SW [file-storage]
358 root 2208 S /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22 -B
367 root 1960 S /sbin/syslogd -n -O /var/log/messages
370 root 1960 S /sbin/klogd -n
374 root 1960 S {start_getty} /bin/sh /bin/start_getty 115200 ttyS0
376 root 2372 S -sh
389 root 1964 S /sbin/getty 115200 ttyGS0
391 root 2372 R ps
I can work around this by not launching the getty process; but obviously then I cannot use the USB gadget for debug.
I would be grateful for any insight in to why this might cause these symptoms
- and for any solution that might allow me to make use of the com port if I needed to
Thanks for the help
Best regards,
Richard
