Stress-testing sysmobts of osmo-bts

[Holger Hans Peter Freyther]

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