summaryrefslogtreecommitdiffstats
path: root/addons/ot/README-pool
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:35:11 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:35:11 +0000
commitda76459dc21b5af2449af2d36eb95226cb186ce2 (patch)
tree542ebb3c1e796fac2742495b8437331727bbbfa0 /addons/ot/README-pool
parentInitial commit. (diff)
downloadhaproxy-upstream.tar.xz
haproxy-upstream.zip
Adding upstream version 2.6.12.upstream/2.6.12upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r--addons/ot/README-pool25
1 files changed, 25 insertions, 0 deletions
diff --git a/addons/ot/README-pool b/addons/ot/README-pool
new file mode 100644
index 0000000..8164b04
--- /dev/null
+++ b/addons/ot/README-pool
@@ -0,0 +1,25 @@
+Used pools:
+
+-------------------------------+-----------------------------+-----------------------------
+ head / name | size | define
+-------------------------------+-----------------------------+-----------------------------
+ pool_head_ buffer | global.tune.bufsize = 16384 | USE_POOL_BUFFER
+ pool_head_ trash | 32 + 16384 | USE_TRASH_CHUNK
+-------------------------------+-----------------------------+-----------------------------
+ pool_head_ ot_scope_span | 96 | USE_POOL_OT_SCOPE_SPAN
+ pool_head_ ot_scope_context | 64 | USE_POOL_OT_SCOPE_CONTEXT
+ pool_head_ ot_runtime_context | 128 | USE_POOL_OT_RUNTIME_CONTEXT
+ pool_head_ ot_span_context | 96 | USE_POOL_OT_SPAN_CONTEXT
+-------------------------------+-----------------------------+-----------------------------
+
+By defining individual definitions in file include/config.h, it is possible to
+switch individual pools on / off. If a particular pool is not used, memory is
+used in a 'normal' way instead, using malloc()/free() functions.
+
+This is made only from the aspect of debugging the program, i.e. comparing the
+speed of operation using different methods of working with memory.
+
+In general, it would be better to use memory pools, due to less fragmentation
+of memory space after long operation of the program. The speed of operation
+is similar to when using standard allocation functions (when testing it was
+shown that pool use was fast by about 1%).