AP_Logger: let the block backend use the configured buffer size - #34172
Open
peterbarker wants to merge 1 commit into
Open
AP_Logger: let the block backend use the configured buffer size#34172peterbarker wants to merge 1 commit into
peterbarker wants to merge 1 commit into
Conversation
LOG_FILE_BUFSIZE is documented as "Logging File and Block Backend buffer size max" with a range of 4 to 200 KiB, but the block backend silently clamped its copy to 64KB after reading it - setting 200 quietly yields 64, only for this backend. The per-board defaults already scale with memory class (16/50/80KB on small boards, ~200KB on large ones), so the clamp only ever engaged on boards with memory to spare - and the allocation loop below it already halves the size until it fits, protecting genuinely memory-short boards without it. The 3x absorption difference is why block-backend logging dropped messages under heavy host load in oversubscribed SITL runs (2680 drops at 85 workers on 32 hardware threads) while the file backend survived the identical load with zero drops across 1184 audited logs: both backends drain through the same wall-clock io thread, and what decides survival of a scheduler stall is how much buffer absorbs the meantime. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
@andyp1per this might interest you. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Removes an ancient clamp on the size of the buffer the dataflash backend is allowed to use
Classification & Testing (check all that apply and add your own)
Description
LOG_FILE_BUFSIZE is documented as "Logging File and Block Backend buffer size max" with a range of 4 to 200 KiB, but the block backend silently clamped its copy to 64KB after reading it - setting 200 quietly yields 64, only for this backend. The per-board defaults already scale with memory class (16/50/80KB on small boards, ~200KB on large ones), so the clamp only ever engaged on boards with memory to spare - and the allocation loop below it already halves the size until it fits, protecting genuinely memory-short boards without it.
The 3x absorption difference is why block-backend logging dropped messages under heavy host load in oversubscribed SITL runs (2680 drops at 85 workers on 32 hardware threads) while the file backend survived the identical load with zero drops across 1184 audited logs: both backends drain through the same wall-clock io thread, and what decides survival of a scheduler stall is how much buffer absorbs the meantime.