Package: bluez-utils Version: 4.57-1 Severity: normal 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. :) -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bluez-utils depends on: ii bluetooth 3.36-3 Bluetooth stack utilities bluez-utils recommends no packages. bluez-utils suggests no packages. -- no debconf information
signature.asc
Description: Digital signature
