Allow newer kernels to opt into explicit loop and chunk limit overrides #2047
Conversation
This file contains 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
Signed-off-by: Dom Del Nano <[email protected]>
Signed-off-by: Dom Del Nano <[email protected]>
oazizi000
approved these changes
Nov 19, 2024
ddelnano
deleted the
ddelnano/allow-explicit-bpf_loop_and_chunk_limits_to_skip_increased_limits
branch
ddelnano
added a commit
to ddelnano/pixie
that referenced
this pull request
Dec 9, 2024
…es (pixie-io#2047) Summary: Allow newer kernels to opt into explicit loop and chunk limit overrides Overwriting non default values of the bpf chunk and loop limit is frustrating since it undoes configuration a user explicitly requested. This also will allow for working around pixie-io#2042, which causes kernels 6.10 and later to fail to start the socket tracer. In addition to this, I tweaked the kernel upgrade logic slightly. The previous logic would have upgraded a 5.0.x kernel to use the new loop limit when the 1M instruction limit isn't available until 5.1. Relevant Issues: Helps to work around pixie-io#2042 Type of change: /kind bug Test Plan: Verified the following on a 6.x kernel running `stirling_wrapper` - [x] Not supplying any arguments results in using an increased loop and chunk limit ``` $ sudo ./bazel-bin/src/stirling/binaries/stirling_wrapper I20241118 05:52:37.358364 3104175 socket_trace_connector.cc:474] Kernel version greater than V5.1 detected (6.8.12), raised loop limit to 882 and chunk limit to 84 ``` - [x] Supplying the loop limit or chunk limit flag disables the automatic increase ``` $ sudo ./bazel-bin/src/stirling/binaries/stirling_wrapper --stirling_bpf_loop_limit=41 I20241118 05:53:21.082810 3104197 source_connector.cc:35] Initializing source connector: socket_tracer I20241118 05:53:21.082886 3104197 kernel_version.cc:82] Obtained Linux version string from `uname`: 6.8.0-1015-gcp I20241118 05:53:21.082916 3104197 linux_headers.cc:395] Detected kernel release (uname -r): 6.8.0-1015-gcp I20241118 05:53:21.082964 3104197 linux_headers.cc:206] Using Linux headers from: /lib/modules/6.8.0-1015-gcp/build. I20241118 05:53:21.083058 3104197 bcc_wrapper.cc:166] Initializing BPF program ... ``` Changelog Message: Ensures that the `--stirling_bpf_loop_limit` and `--stirling_bpf_chunk_limit` values are respected if explicitly provided on the command line. For 5.1 and later kernels, cli provided values would have been ignored --------- Signed-off-by: Dom Del Nano <[email protected]>
ddelnano
added a commit
that referenced
this pull request
Dec 16, 2024
Summary: Fix release note generation script Our releases have blank release notes. This makes it difficult for end users to understand what has changed between releases. This PR updates the existing script that was built to auto generate changelog notes. Relevant Issues: N/A Type of change: /kind bug Test Plan: Ran the script for each artifact type and verified the output was expected - [x] cli release notes are expected ``` $ ./scripts/create_release_tag.sh cli -n $ git tag -l --format='%(contents)' release/cli/v0.9.0-pre-ddelnano-fix-release-note-generation.4 ### New Features - (#2048) Enhanced the `px` cli to detect OpenShift clusters and prompt to install the appropriate SecurityContextConstraints before proceeding with a deploy ``` - [x] vizier release notes are expected ``` # Needed to modify prev_tag in script since v0.14.13 to main's HEAD doesn't have vizier changelog messages $ ./scripts/create_release_tag.sh vizier -n $ git tag -l --format='%(contents)' release/vizier/v0.15.0-pre-main.4 ### Bug Fixes - (#2047) Ensures that the `--stirling_bpf_loop_limit` and `--stirling_bpf_chunk_limit` values are respected if explicitly provided on the command line. For 5.1 and later kernels, cli provided values would have been ignored ``` - [x] cloud release notes are generated correctly ``` $ ./scripts/create_release_tag.sh cloud -n Generating changelog from release/cloud/v0.1.8..release/cloud/v0.2.0-pre-ddelnano-fix-release-note-generation.1 $ git tag -l --format='%(contents)' release/cloud/v0.2.0-pre-ddelnano-fix-release-note-generation.1 ### New Features - (#2043) Add support for rendering differential flamegraphs in the `StackTraceFlameGraph` display spec ### Bug Fixes - (#2041) Upgraded bcc and libbpf to support kernels 6.10 and later ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: Allow newer kernels to opt into explicit loop and chunk limit overrides
Overwriting non default values of the bpf chunk and loop limit is frustrating since it undoes configuration a user explicitly requested. This also will allow for working around #2042, which causes kernels 6.10 and later to fail to start the socket tracer.
In addition to this, I tweaked the kernel upgrade logic slightly. The previous logic would have upgraded a 5.0.x kernel to use the new loop limit when the 1M instruction limit isn't available until 5.1.
Relevant Issues: Helps to work around #2042
Type of change: /kind bugfix
Test Plan: Verified the following on a 6.x kernel running
stirling_wrapperChangelog Message: Ensures that the
--stirling_bpf_loop_limitand--stirling_bpf_chunk_limitvalues are respected if explicitly provided on the command line. For 5.1 and later kernels, cli provided values would have been ignored