mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2026-01-12 20:31:01 +01:00
facfad2b64
Pools are being used so well that it becomes difficult to profile their usage via the regular memory profiling. Let's add new entries for pools there, named "p_alloc" and "p_free" that correspond to pool_alloc() and pool_free(). Ideally it would be nice to only report those that fail cache lookups but that's complicated, particularly on the free() path since free lists are released in clusters to the shared pools. It's worth noting that the alloc_tot/free_tot fields can easily be determined by multiplying alloc_calls/free_calls by the pool's size, and could be better used to store a pointer to the pool itself. However it would require significant changes down the code that sorts output. If this were to cause a measurable slowdown, an alternate approach could consist in using a different value of USE_MEMORY_PROFILING to enable pools profiling. Also, this profiler doesn't depend on intercepting regular malloc functions, so we could also imagine enabling it alone or the other one alone or both. Tests show that the CPU overhead on QUIC (which is already an extremely intensive user of pools) jumps from ~7% to ~10%. This is quite acceptable in most deployments.