mirror of
				https://git.haproxy.org/git/haproxy.git/
				synced 2025-10-29 23:51:01 +01:00 
			
		
		
		
	This one is the last optional module to build with haproxy, so let's move it to addons/. It was renamed to "ot" as it was the only one whose USE_* option did not match the directory name, now this is consistent. Few changes were required, only the Makefile, and doc were adjusted, as the directory was already self-contained and relocatable.
		
			
				
	
	
		
			26 lines
		
	
	
		
			1.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			26 lines
		
	
	
		
			1.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 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%).
 |