Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scx_lavd: fix CI error for missing kernel symbols #885

Merged
merged 2 commits into from
Nov 4, 2024

Conversation

multics69
Copy link
Contributor

Revised the lock tracking code, relying on stable symbols with various kernel configurations. There are two changes:

  • Entirely drop tracing rt_mutex, which can be on and off with kconfig

  • Replace mutex_lock() families to __mutex_lock(), which is stable across kernel configs. The downside of such a change is it is now possible to trace the lock fast path, so lock tracing is a bit less accurate. But let's live with it for now until a better solution is found.

Changwoo Min added 2 commits November 4, 2024 16:05
Revised the lock tracking code, relying on stable symbols with various
kernel configurations. There are two changes:

- Entirely drop tracing rt_mutex, which can be on and off with kconfig

- Replace mutex_lock() families to __mutex_lock(), which is stable
  across kernel configs. The downside of such change is it is now
  possible to trace the lock fast path, so lock tracing is a bit less
  accurate. But let's live with it for now until a better solution is found.

Signed-off-by: Changwoo Min <[email protected]>
Copy link
Contributor

@arighi arighi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, lavd is much more portable now, thanks!

Thinking more about this, it might be actually a good thing to not track the fastpath, if there's only one task that acquired the lock without any other concurrent task there's no contention, so no risk of priority inversion, hence it's probably fine if the task follows the "normal scheduling rules". If we want to be more precise, an option could be to inspect lock->owner in the slowpath and increment the lock_boost of the owner task from there.

@multics69 multics69 added this pull request to the merge queue Nov 4, 2024
Merged via the queue into sched-ext:main with commit 060a166 Nov 4, 2024
21 checks passed
@multics69 multics69 deleted the ci-fix-v2 branch November 4, 2024 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants