Adding upstream version 2.6.12.upstream/2.6.12upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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%).