I was testing asterisk with a bt dongle on an ARM router using a configuration that worked ok on an intel laptop and noticed that the load was always staying about about 1.0 even though the system was doing nothing.
I enabled thread tracing and noticed that chan mobile has, what could only, in my humble opinion be described as some stupid 1ms polling in a thread on file descriptors that you can only assumed would be available by something like select.
I changed the code to run every 100ms thinking that some threads elsewhere were adding data when a call and audio were present. The diff is below, and I noticed no real impact, apart from the low to settling down to about 0.05 to 0.20 which is about normal for the stuff that runs on t he router.
@@ -4317,11 +4316,37 @@
* This thread accepts new sco connections and handles audio data. There is
* one do_sco_listen thread for each adapter.
*/
+struct io_context {
+ struct pollfd *fds; /*!< Poll structure */
+ struct io_rec *ior; /*!< Associated I/O records */
+ unsigned int fdcnt; /*!< First available fd */
+};
+
static void *do_sco_listen(void *data)
{
struct adapter_pvt *adapter = (struct adapter_pvt *) data;
-
+ struct pollfd fds[16];
+ int fdcount = 0;
+ int i;
while (!check_unloading()) {
+ int tmp = fdcount;
+ int startVal = -1;
+ int res;
+ fdcount = adapter->accept_io->fdcnt + adapter->io->fdcnt;
+ if (tmp != fdcount) {
+ // fprintf(stderr, "Fs changed from %d to %d\n", tmp, fdcount);
+ }
+ for(i = 0; i < adapter->accept_io->fdcnt; ++i) {
+ fds[i] = adapter->accept_io->fds[i];
+ }
+ for(startVal = adapter->accept_io->fdcnt ; i < fdcount; ++i) {
+ fds[i] = adapter->io->fds[i - startVal];
+ }
+ // 100ms
+ if ((res = ast_poll(fds, fdcount, 100)) == 0) {
+ continue;
+ }
+ //fprintf(stderr, "Have crap\n");
/* check for new sco connections */
if (ast_io_wait(adapter->accept_io, 0) == -1) {
/* handle errors */