Hi,

I have pushed zecke/work/msgq-reading2 with a work in progress improvement for handling a load from a stress-test. The stress test is to allocate all lchan's at the same time (then let them fail through the radio link timeout) and re-allocate them.

This forces the BTS to constantly need to open/close the logical channel resources and also send some (idle) frames (LAPDm is not established in this case). The BTS was sending frames too late and after looking at it with perf it looked like a latency issue (no one is really using the CPU).

I have implemented various changes, not all of them are ready:

* Change the Bad-Frame-Indicator level to have radio link timeouts with no phone being present. In the above test-case channels remained open as there was no bad-frame-indication on these channels.

Pro: There is a constant load for all open channels Bad: We could do this as part of the MphTimeInd but then need to add a bit to the counter to remember if the counter was modified and we need to handle bad frame in two places.

* Use writev for the write_queue. This code should/could move into the libosmocore. So for our primitives queue all primitives are the same length and we can use writev to write several frames as the same time.

1.) We go through the queued messages and add them to the iovec 2.) We use writev 3.) We do written / prim_size to see how many buffers were written 4.) We go throuh the queued messages with llist_for_each_entry_safe and remove the count of messages sent. 5.) We check if there are messages left and re-set the notify on writable bit.

* Use readv for reading from the queue. This means that we need to allocate N msgb's, call readv, dispatch the messages, free the extra msgb's.

Pro: In idle mode there is at least one message to read, with channels open it is likely we will read several messages at once. Bad: Allocating memory is not free. We could start using talloc pools, we could add a msgb_alloc_headroom that does not memset (talloc_zero) the memory.

* The above made noticable differences but I also had to get the realtime hammer. I have decided to use SCHED_RR (instead of SCHED_FIFO). This is done with osmo-pcu in mind that needs to read from queues as well and both bts/pcu should be able to inerrupt each other.

* For the ts_meas_check_compute we can stop processing the entire TS once we reach a lchan of type lchan == GSM_LCHAN_NONE. (We still need to add a memset of the lchan array into the oml.c code in case there is a re-config).

TCH/F: Only lchan[0] is used. TCH/H: Only lchan[0,1] are used. SDCCH8: All of them are used CCCH: lchan[4] is used but we will have no power measurements anyway CCCH/SDCCH4: lchan[0-3] are used.

What is not done:

* Change the l1if primitive to either use or 'steal' the msgb. All the msgb_free could be removed, only if we forward the MSGB to the PCU socket we would 'steal' it. This would allow us to avoid calling msgb_alloc and msgb_free most of the time.

* Add SCHED_RR to the pcu code as well.

* Create a talloc pool for the primitives (or re-use the msgb across multiple reads).

please review and comment holger