Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
Also change linpool.current ptr to really point to thr current chunk.
|
|
|
|
|
|
|
|
|
|
|
|
This also fixes bug that timer->recurrent was not cleared
in tm_new() and unexpected recurrence of startup timer
in BGP confused state machine and caused crash.
|
|
Not quite standard construction, i should add
some autoconf macro.
Not tested yet.
|
|
|
|
|
|
|
|
to see what resource does the address given as a parameter belong to.
|
|
and other non-portable functions on all systems.
|
|
|
|
|
|
|
|
memory available for subsequent allocations from the same pool. Both flushing
and re-using the memory costs just few instructions.
|
|
- cfg_strcpy() -> cfg_strdup()
- mempool -> linpool, mp_* -> lp_* [to avoid confusion with memblock, mb_*]
Anyway, it might be better to stop ranting about names and do some *real* work.
|
|
|
|
Complete resource manages and IP address handling.
|