Bug #913
closed
Does piboxd take too much CPU?
100%
Description
On an 1.2 release of auto-kiosk, piboxd is taking 25% cpu on an RPi2. And that's without anything else running - no launcher, no apps. So something is really wrong there.
This may have been fixed with the use of semaphores but I need to check to be certain. I may have only added semaphore usage to the apps and not piboxd.
Related issues
Updated by Hammel about 2 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
A cursory examination suggests the problem is with smb or timer threads. These should be changed to use a semaphore and to run less often.
The main loop could also be changed to a semaphore instead of checking the state flag once a second.
Updated by Hammel about 2 years ago
- % Done changed from 10 to 30
Running in autokiosk mode with the following
piboxd -I -S -sreduces the CPU load of piboxd to around 0.5% to 0.7%. This heavily suggests that the various threads are poorly written in piboxd, with the smb thread the most likely culprit.
Updated by Hammel about 2 years ago
- Related to Bug #916: Autokiosk mode should run piboxd with -I -s -S to disable IoT, smb and camera streams. added
Updated by Hammel about 2 years ago
Further review of the code suggests that neither the timer or smb is likely the culprit, but that the registration processor (-I) is. The latter does a non-blocking recvfrom() in order to allow breaking out of the thread loop. This obviously causes very fast loop processing that's likely chewing up CPU time.
The fix is to simply add a select() with a timeout on the socket descriptor.
Updated by Hammel about 2 years ago
- Status changed from In Progress to Closed
- % Done changed from 30 to 100
Added use of select() in regProcessor and main thread. The former removes a tight loop that was chewing up lots of processor time. The latter removes a less problematic loop and frees up more cpu time. Result is piboxd went from 20%+ CPU usage down to >1% cpu usage. The update is so good that time to launch omxplayer has really improved. Overall performance is much snappier.
Code has been tested on hardware, committed and pushed.
Closing issue.