Skip to contentSkip to conversation

New: rfcomm causes very high cpu usage during serial connectivity

Bug 205579 Stephen Hemminger 1 participant 1 message Nov 19, 2019 Bluetooth drivers

lore
Share & tools
lore
#0 lore raw

Begin forwarded message:

Date: Tue, 19 Nov 2019 09:52:12 +0000
From: [email protected]
To: [email protected]
Subject: [Bug 205579] New: rfcomm causes very high cpu usage during serial connectivity

https://bugzilla.kernel.org/show_bug.cgi?id=205579

Bug ID: 205579
Summary: rfcomm causes very high cpu usage during serial
connectivity
Product: Networking
Version: 2.5
Kernel Version: Everything
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: [email protected]
Reporter: [email protected]
Regression: No

This appears to be a long standing issue that is mentioned only in old Debian bug reports and current Raspbian discussions but it remains important for embedded systems because they are not powerful systems.

Sources:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565485
https://www.raspberrypi.org/forums/viewtopic.php?t=181796

Issue Description:

"I use 'rfcomm listen' in combination with 'gpspipe' to relay GPS data from my eeePC to my Blackberry. I noticed, however, that the CPU overhead from 'rfcomm listen' is quite significant -- over 10% on my eeePC 901.

Running 'strace' reveals that rfcomm is in a tight loop between 'waitpid' (with WNOHANG) and 'ppoll' (with a 200 nanosecond(!!) timeout). This is evidently the source of the extreme CPU usage.

If it's critical that rfcomm know the child has died ASAP, I would expect it should be watching for the SIGCHLD signal rather than trying to use waitpid(). If it's not all that critical, it probably doesn't need to be watching for child death at a rate of five millions checks per second. :)"

also

"I am experimenting with a serial connection to Pi Zero W using the on-board Bluetooth module. I can successfully establish a connection and send data to Pi. However as soon as the connection starts, the rfcomm process consumes almost 50% of the processor (as top shows). This noticeably slows down other processes."

The issue remains on current code.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.