-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
P&F: Enable support for indexes in watch tracker #105974
Conversation
return w.forgetWatch(identifier, index) | ||
} | ||
|
||
func (w *watchTracker) updateIndexLocked(identifier *watchIdentifier, index *indexValue, incr int) { |
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.
Obviously we want to add tests for it before submitting - but I wanted to get your thoughts if this is acceptable (for the sake of making progress on it).
@MikeSpreitzer @tkashem
/triage accepted |
/lgtm |
didn't realize that verify is failing, looks good to me otherwise /lgtm cancel |
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 is certainly safe while we have the usage of these watch counts disabled!
Considering that we had no usage of watch counts in earlier releases, I think this would be a safe step to take even the watch counts get used.
// builtinIndexes represents of set of indexes registered in | ||
// watchcache that are indexing watches and increase speed of | ||
// their processing. |
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 would be good to include an explanation of what the keys and values are.
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.
added
watchCount map[watchIdentifier]int | ||
} | ||
|
||
func NewWatchTracker() WatchTracker { | ||
return &watchTracker{ | ||
watchCount: make(map[watchIdentifier]int), | ||
indexes: getBuiltinIndexes(), |
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 would order the fields in this construction the same as in the struct definition.
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.
done
// empty value (we assume that number of those for empty value is not | ||
// smaller than for any other value). That's not always true, but in |
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 think the assumption being made here is rather that the count for not-unset non-empty value stays tiny in absolute terms.
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.
Not exactly (and what you're saying is also not true in practice - e.g. each kubelet is watching for its own pods, which means that there are N such watches with N being number of nodes).
The observation is that for a given object create/update/delete the amount of work (also filtering given index implementaion in watchcache) is proportional to:
- watches interested in all objects (those that are "unset" here)
- watches interssted in the value coming from that object
So we're basically assuming (which seem to be true in practice too), that the difference between "unset + my-value" is small comparing to "unset + empty".
Tried to clarify the comment.
3a8f222
to
21ec77d
Compare
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.
@MikeSpreitzer @tkashem - PTAL
// builtinIndexes represents of set of indexes registered in | ||
// watchcache that are indexing watches and increase speed of | ||
// their processing. |
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.
added
watchCount map[watchIdentifier]int | ||
} | ||
|
||
func NewWatchTracker() WatchTracker { | ||
return &watchTracker{ | ||
watchCount: make(map[watchIdentifier]int), | ||
indexes: getBuiltinIndexes(), |
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.
done
// empty value (we assume that number of those for empty value is not | ||
// smaller than for any other value). That's not always true, but in |
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.
Not exactly (and what you're saying is also not true in practice - e.g. each kubelet is watching for its own pods, which means that there are N such watches with N being number of nodes).
The observation is that for a given object create/update/delete the amount of work (also filtering given index implementaion in watchcache) is proportional to:
- watches interested in all objects (those that are "unset" here)
- watches interssted in the value coming from that object
So we're basically assuming (which seem to be true in practice too), that the difference between "unset + my-value" is small comparing to "unset + empty".
Tried to clarify the comment.
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.
Yes, this looks like a good start.
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: MikeSpreitzer, wojtek-t The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
Ref #105804
/kind bug
/priority important-soon
/sig api-machinery
/assign @MikeSpreitzer @tkashem