Remove (by design) memory-leak by from the Intervals Results linked-list #1814
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Version of iperf3 (or development branch, such as
master
or3.1-STABLE
) to which this pull request applies:master
Issues fixed (if any): may fix Significant jitter increase from 3.6 to 3.17 #1806
Brief description of code changes (suitable for use as a commit message):
Intervals Results history is saved in a linked list, but is seems that this history is not used (history is used only as JSON or printed output). Therefore, keeping this linked list cause unnecessary memory usage and practically this is a memory leak. As each entry i the list is about 400 bytes, with 0.1 sec interval, about 15MB are allocated per one stream per hour, which is about 350MB for one day test per stream.
I suspect that #1806 problem after running for 3 hours with 24 streams was caused by this memory leak (although this is not confirmed yet).
This PR suggest the removal of the Interval Results history, by removing the last entry when allocating a new one. Practically making 1 the maximum list length.
The suggested change is not optimal, as it removes the old entry and then insert the new one. A better approach may be to replace the last entry, just reuse the last entry, or even don't use a linked list at all. However, since the operation is relatively not frequent, the chosen approach seems to be good enough with lower risk.