Skip to content
  • Maria Matejka's avatar
    f772afc5
    Memory statistics split into Effective and Overhead · f772afc5
    Maria Matejka authored
    This feature is intended mostly for checking that BIRD's allocation
    strategies don't consume much memory space. There are some cases where
    withdrawing routes in a specific order lead to memory fragmentation and
    this output should give the user at least a notion of how much memory is
    actually used for data storage and how much memory is "just allocated"
    or used for overhead.
    
    Also raising the "system allocator overhead estimation" from 8 to 16
    bytes; it is probably even more. I've found 16 as a local minimum in
    best scenarios among reachable machines. I couldn't find any reasonable
    method to estimate this value when BIRD starts up.
    
    This commit also fixes the inaccurate computation of memory overhead for
    slabs where the "system allocater overhead estimation" was improperly
    added to the size of mmap-ed memory.
    f772afc5
    Memory statistics split into Effective and Overhead
    Maria Matejka authored
    This feature is intended mostly for checking that BIRD's allocation
    strategies don't consume much memory space. There are some cases where
    withdrawing routes in a specific order lead to memory fragmentation and
    this output should give the user at least a notion of how much memory is
    actually used for data storage and how much memory is "just allocated"
    or used for overhead.
    
    Also raising the "system allocator overhead estimation" from 8 to 16
    bytes; it is probably even more. I've found 16 as a local minimum in
    best scenarios among reachable machines. I couldn't find any reasonable
    method to estimate this value when BIRD starts up.
    
    This commit also fixes the inaccurate computation of memory overhead for
    slabs where the "system allocater overhead estimation" was improperly
    added to the size of mmap-ed memory.
Loading