aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorYves Godin <yves.godin@nutaq.com>2015-12-07 10:27:46 -0500
committerHarald Welte <laforge@gnumonks.org>2016-02-15 14:26:44 +0100
commitb936bd7162f29cab0cfe2d31139a5ffd997b029e (patch)
tree570186e811f1d6006272b5dcf3e59c93a62042f2
parent6e1aed4b230a8e9be53ab487515ba10723ef99b3 (diff)
LC15: use talloc pool for msgb and ortp library
by using a talloc pool, we avoid having to go back to the libc malloc pool all the time. The msgb allocations and libortp allocations happen quite frequently during processing and show up as one of the high priority items in osmo-bts profiles on sysmoBTS with 14 concurrent TCH/H calls (highest load scenario). talloc still consumes significant CPU, this is mostly due to the zero-initialization of all the associated buffers. Strictly speaking we shouldn't need this, but any change there would require lots of testing, as there might be hidden assumptions in the code? In some percentage of cases, talloc still seems to fall back on malloc for msgb allocations, which is currently a bit of a mystery. The pools certainly are large enough, talloc_reprt() rarely reports more than a few tens of kilobytes used by the msgb pool. From 2ecbf871301cdc36c0212dd7526fc94ffa4597d1
-rw-r--r--src/osmo-bts-litecell15/main.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/osmo-bts-litecell15/main.c b/src/osmo-bts-litecell15/main.c
index 3298ba52..6e8ca0d5 100644
--- a/src/osmo-bts-litecell15/main.c
+++ b/src/osmo-bts-litecell15/main.c
@@ -314,7 +314,7 @@ int main(int argc, char **argv)
tall_bts_ctx = talloc_named_const(NULL, 1, "lc15BTS context");
- tall_msgb_ctx = talloc_named_const(tall_bts_ctx, 1, "msgb");
+ tall_msgb_ctx = talloc_pool(tall_bts_ctx, 100*1024);
msgb_set_talloc_ctx(tall_msgb_ctx);
bts_log_init(NULL);