-
Notifications
You must be signed in to change notification settings - Fork 41.5k
Don't take the proxy mutex in the traffic path #13345
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
Conversation
GCE e2e build/test passed for commit 36768020505aa02afc2e311e0c4967d48f4787ed. |
pkg/proxy/userspace/proxier.go
Outdated
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.
at struct creation time, are all the the field values in the struct guaranteed to be visible on all threads ?
The Go memory model didnt seem to call it out explicitly.(unless I missed it )
This also impacts other fields in the struct.
Otherwise, looks good to me.
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.
Are you suggesting that another thread might still see this as a non-1 value? Or am I missing the implication? setServiceInfo DOES take the mutex, so any memory write before that must have been visible to other processors.
This should be cherry picked into 1.0 - it's a real problem. |
@k8s-oncall for a prio merge |
pkg/proxy/userspace/proxier_test.go
Outdated
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.
Please write an IsAlive() predicate on svcInfo so everyone will get this right.
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.
yeah, I knew I should have done that. next push
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, it would be good to capture this in a variable, to ensure that your log message sees the same thing the if statement sees.
3676802
to
caa010c
Compare
new push is up |
This should make throughput better on the userspace proxier. Fixes kubernetes#11977
caa010c
to
f0a9bad
Compare
As far as cherry picking goes, I think you need to make a cherry-pick PR separately with cherry_pick_pull.sh. |
Yeah, I'll cherry pick it one LGTY |
shippable did not start |
LGTM was before last commit, removing LGTM |
LGTM |
Am trying to figure out what the merge queue is doing. |
GCE e2e build/test failed for commit caa010cbcf04b0aef7f22c2c2fb776f4c637826c. |
GCE e2e build/test passed for commit f0a9bad. |
The merge queue is blocked because our tests are not stable. #13236 is the biggest and possibly only offender. |
Don't take the proxy mutex in the traffic path
@thockin shippable failed on master after I merged this-- I'm going to roll it back shortly. |
Hm, I can't repro locally... |
I can't repro locally, and it's only flaky, not perma broken:
|
It's too flaky. I'm going to roll back. Sorry. |
Hm, maybe the rollback didn't help? Sigh |
No, it did help, I was just confused by shippable's ordering. |
…5-upstream-release-1.0 Automated cherry pick of #13345 upstream release 1.0
This should make throughput better on the userspace proxier.
Fixes #11977
@bnprss I think this will fix your problems well enough that #12017 can be abandoned.