Hi all,
I've been doing some profiling on osmo-bts recently (on sysmobts
hardware, which has only a relatively slow ARM926 CPU core), and the two
things that show up most are:
* msgb_alloc() -> talloc_zero() -> malloc
this can be alleviated somewhat by using talloc pools. For some
reason the pools don't remove all of the malloc() calls.
* vfprintf() and friends, from logp() statements. The sad part is that
calls like gsm_lchan_name() are of course executed beefore the call
into logp(), at which point the vfprintf/sprintf/... for arguments has
already been executed, and only the last/final one hasn't happened
yet.
Here we can do two things: Calls like gsm_lchan_name() don't need to
happen all the time, as the lchan name is static and can be generated
once at the time gsm_lchan is created. I implemented that in osmo-bts
(and openbsc, as it's from gsm_data_shared).
The second idea would be to expand the LOGP() macro a bit in a way to
ensure the the checking whether the log line is enabled _before_ the
arguments (and thus associated function calls) are evaluated. Any
ideas on that?
After a brief look at osmo-pcu profiling, it looks like in the
attached picture. We cannot do much about the __copy_to_user_std,
do_select and core_sys_select, as those are kernel side.
However, there again we see vfprintf and friends, mostly via
gprs_rlcmac_tbf::name() - and of course the msgb_alloc() and msgb_free()
going through talloc and finally malloc.
So the same strategies as above could (and probably should) be applied
to osmo-pcu.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)