-
Notifications
You must be signed in to change notification settings - Fork 989
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
Clean up a hostinfo to reduce memory usage #955
Conversation
3656e8c
to
95da1f6
Compare
88b2091
to
cb88583
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.
First read through, mostly concerns about the locking changes
@@ -350,22 +340,6 @@ func ixHandshakeStage2(f *Interface, addr *udp.Addr, via *ViaSender, hostinfo *H | |||
} | |||
|
|||
ci := hostinfo.ConnectionState | |||
if ci.ready { |
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.
if we remove this ci.ready check, I think we need a different double check after the hh.Lock()
to see if a different thread already completed the handshake for this host? How do we protected about late handshake packets coming 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 expect in this version it would fail when trying to read a noise message. The next PR in the series would put these calls to ixHandshake*
within the pending hostmap lock to avoid these races.
hostinfo.Lock() | ||
defer hostinfo.Unlock() |
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.
The race detector might get upset about this, even if its okay in theory. I guess we can see what happens.
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 looks like its fine, at least running make smoke-docker-race
shows no race detector complaints during the smoke test.
hh.Lock() | ||
defer hh.Unlock() |
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 everytime we do a lock like this, we need to double check afterwards if another thread beat us to finishing out this entry, right? (or add a comment about why no-one could have beat us to it).
hostinfo.Lock() | ||
defer hostinfo.Unlock() |
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.
Why don't we need this anymore? Shouldn't be at least doublecheck that someone else didn't already handle a recv_error for this hostinfo on a different thread?
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.
The lock didn't really do anything for us before. If we have two threads in this code path and 1 is temporarily blocked on the hostinfo lock, they will have the same outcome.
ec9d8a4
to
0fee9a7
Compare
This removes a lot of state from
HostInfo
to reduce our memory footprint for active tunnels.