-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[EBPF-595] Create a common process consumer for eventmonitor #30559
[EBPF-595] Create a common process consumer for eventmonitor #30559
Conversation
ed95e39
to
fd3481e
Compare
Regression Detector |
fd3481e
to
0b2b370
Compare
0b2b370
to
1a38ab4
Compare
1a38ab4
to
52219d7
Compare
[Fast Unit Tests Report] On pipeline 48141503 (CI Visibility). The following jobs did not run any unit tests: Jobs:
If you modified Go files and expected unit tests to run in these jobs, please double check the job logs. If you think tests should have been executed reach out to #agent-devx-help |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed
callbacks map[*ProcessCallback]struct{} | ||
|
||
// mutex is the mutex that protects the callbacks map | ||
mutex sync.RWMutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the common pattern to use this struct?
in some cases rwmutex perform worse than the regular mutex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took the same pattern as there is in process-monitor, I assumed it was tested to be the best option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
common use case - adding all callbacks (write lock), and then calling them (read lock)
normally, all callbacks are being added (or removed) before (or after) the operation.
We can use regular mutex here, but, if we do intend to make the change - it should be tested to show it improves the usage of rwmutex
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
me and @brycekahle discussed rwmutex in some other context. and in some cases the rwmutex actually creates slight overhead (even when just using the readerlock without writer lock).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can do that, we're always going to (potentially) have two goroutines accessing the callback map concurrently, one from the event stream and another one from the subscription.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have any subscriptions happening in "execution" phase or rather we can limit the subscription during the "init" phase before the handler go-routine starts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also these benchmarks for reference
(maybe sync.Map
is a better choice)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not always be possible to limit the subscriptions, specially considering that the current way of adding event stream consumers requires having a global variable to share the consumer, and that could probably change later. Also, it'd require changing the SubscribeX
signatures to be able to return an error.
I think it's a good idea to research this a bit more, but I think we should have a better view of dependencies in system-probe modules first to see how that fits with those phases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree that we can leave it out of scope for this PR. Resolving the comment
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: inv create-vm --pipeline-id=48141503 --os-family=ubuntu Note: This applies to commit d632825 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed
/merge |
🚂 MergeQueue: pull request added to the queue The median merge time in Use |
What does this PR do?
This PR adds a
ProcessConsumer
type that can be directly used by callers interested just in exec/exit callbacks without having to manually implement all the necessary interfaces.Motivation
Removing coupling between
UprobeAttacher
andProcessMonitor
, which caused problems with the process monitor initialization being called in multiple places. This PR allows GPU and DI module to use a consumer for the event monitor stream quickly, without having to copy-paste existing code.Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes
Related PR: #30554