-
Notifications
You must be signed in to change notification settings - Fork 2.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
Address ipcache startup perfomance regression #25007
Address ipcache startup perfomance regression #25007
Conversation
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.
Thanks for the fix, nice work! The fix looks good to me, I have a few minor questions below.
Just a nit on the commit msg: technically the namedport map is not the only lock being held while it's locked; the ipcache lock is always held before the namedport map lock is taken. Actually, it seems like we should "promote" this relationship to say that the ipcache lock must be taken before the namedport map.
123f3e2
to
cbcb6f8
Compare
/test |
cbcb6f8
to
23d9b0d
Compare
What I was trying to express in the commit message was that we don't acquire a new lock while holding the namedport mutex (M), and hence don't establish any relations of the form M > X, for any X. I think that's correct. But yes, we do hold the ipcache mutex while acquiring the namedport mutex, and establish IPCache > M. This is precisely why it's crucial to not acquire any other mutex while also holding M. Tests were green before pushing to clarify the commitmsg and fix a cosmetic issue in the benchmark, but more reruns can't hurt. I've also dropped the |
/test Job 'Cilium-PR-K8s-1.25-kernel-5.4' failed: Click to show.Test Name
Failure Output
Jenkins URL: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.25-kernel-5.4/66/ If it is a flake and a GitHub issue doesn't already exist to track it, comment |
/mlh new-flake Cilium-PR-K8s-1.25-kernel-5.4 👍 created #25042 |
/test-1.25-5.4 |
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.
Awesome work, thanks for taking care of this! 🙏
There is one issue around ipc.needNamedPorts
and the externally visible behavior that I'm not sure how to address, see inline comment.
23d9b0d
to
56a943c
Compare
56a943c
to
cb4cec8
Compare
/test-1.24-5.4 (Required tests have changed, running the new ones now) |
/test-1.25-4.19 |
/test-1.26-net-next |
CI triage:
I'll gamble one rerun and otherwise rebase and run it all again |
/test-1.26-net-next No bueno. Rebasing and let's run it all. |
This patch adds a benchmark for ipcache.Upsert, with the intention of exercising the logic for named ports. This exposes a performance regression when upserting many pods, as is the case on agent startup. The startup regression was due to losing an optimization in 93cd67f, namely that the named ports bookkeeping is done only once named ports are present in policies. Without the lazy bookkeeping, we have accidentally quadratic behavior, as we look at every pod whenever a new pod is added. Follow up commits will address the issue, this is merely a convenient reproduction of the regression. Suggested-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
In preparation of introducing reference counting for named ports, change the NamedPortMultiMap from a concrete type to an interface. This produces a fair bit of churn in the test code (as it assumes the type is a map). There are no functional changes, however. The benefit of having this type be an interface is that we can switch it's implementing type to use reference counting with a smaller patch. That, in turn, will allow us to avoid looking at all other pods when a new pod is added or deleted, just for the named port bookkeeping. Suggested-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
This commit introduces reference counting for named ports. Using the reference counting, we know when to add or remove named ports in our bookkeeping, without having to look through all other pods. This leads to a significant speedup when inserting many pods, as is the case on agent startup. Note that this patch does _not_ restore the original optimization of not keeping track of named ports until used in a policy. We did not find a good way of doing so while also avoiding re-introducing the deadlock fixed in the commit referenced below. Instead, we always do the bookkeeping, but in a more efficient manner. The reference counting requires the use of a RWLock, since read and write accesses to a map must be protected. Thus, there is potential for introducing yet another deadlock. However, we argue that this is not the case: We do _not_ acquire any other lock while holding our mutex M. A wait cycle/deadlock involving M must include holding M when acquiring some other lock, however. Therefore this patch cannot introduce a deadlock. Fixes: 93cd67f (ipcache: fix potential deadlock in GetNamedPorts) Fixes: cilium#24987 Suggested-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
With the reference counting in place, we can simplify the involved code paths in the ipcache. There is now little point to conditionally perform the update, as the update itself is about as expensive as checking whether it is necessary. Therefore, opt for simpler code and always call into NamedPortMultiMapUpdater.Update. Indeed, this even gives a mild speedup: goos: linux goarch: arm64 pkg: github.com/cilium/cilium/pkg/ipcache │ fix.txt │ cleanup.txt │ │ sec/op │ sec/op vs base │ IPCacheUpsert10-10 48.84µ ± 5% 47.59µ ± 5% ~ (p=0.165 n=10) IPCacheUpsert100-10 508.3µ ± 5% 485.0µ ± 2% -4.58% (p=0.005 n=10) IPCacheUpsert1000-10 5.282m ± 5% 5.056m ± 2% -4.28% (p=0.011 n=10) IPCacheUpsert10000-10 48.63m ± 5% 44.87m ± 5% -7.74% (p=0.009 n=10) geomean 1.589m 1.513m -4.81% Suggested-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
eb1b776
to
df332c9
Compare
/test |
The commit messages should be descriptive, here's the summary line for each.
regression.txt
below)interface.txt
below)fix.txt
below)cleanup.txt
below)The following is a comparison of running the benchmark added in commit 1 over the course of the four commits.
The last commit,
cleanup.txt
removes some now redundant work, and hence gets a mild speedup. If preferred, it can be squashed into the third commit, but like this the algorithmic changes are easier to understand.Note that simply reverting 93cd67f is not actually a fix, as the quadratic behaviour still lurks. This can be observed by forcefully setting
ipcache.needNamedPorts = true
when benchmarking:Fixes: #24987