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
dnsproxy: Remove usage of regex lru #22584
Conversation
Ref. #22241 this will make all users able to utilize the benefits from #21288 when it comes to memory usage of unused regexes. Not sure if we should remove all of it at once tho. Any thoughts @christarazi ? |
@@ -347,7 +347,7 @@ func (c regexCache) lookupOrCompileRegex(pattern string) (*regexp.Regexp, error) | |||
entry.referenceCount += 1 | |||
return entry.regex, nil | |||
} | |||
regex, err := re.CompileRegex(pattern) | |||
regex, err := regexp.Compile(pattern) |
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 we can update the godoc on re.CompileRegex to say it's deprecated and not to use it.
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.
Additionally, searching for all instances of re.CompileRegex
and replacing them could work. Or alternatively, you could just make re.CompileRegex
simply be a wrapper for regexp.Compile
, that way you don't risk missing any paths.
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.
We can then remove this code in the v1.14 release cycle after we've deprecated it properly here.
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.
Finally back from 🌴 now, so ready to keep pushing these!
Do you have a preference here? I think a cache for the other usage of re.CompileRegex
might be valuable to avoid compiling them all the time, but I don't have all the context on that.
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.
On second thought, maybe we don't want to entirely remove the LRU.
The problem with caching regexes as we've learned is if we don't clean them up. In your fixes, you've attached a refcount to the regex in the DNS proxy. But there are other areas too, where we can attach cleanup logic.
The other areas for regex compilation is policy YAML validation, aka pkg/fqdn/matchpattern.Validate()
and during each DNS request in the DNS proxy. I see value in caching the regex in these cases.
In the former case, we could mitigate the issue of keeping the regexes around by hooking into the policy-delete event and removing the names (which map to regexes) in the to-be-deleted policy from the cache. In the latter case, we can use an LRU. I feel an LRU is suitable in this case because the access pattern will be based on the DNS requests that the workloads are performing.
Should these cases share the same LRU? Well, that was kinda the idea behind the initial LRU implementation to begin with. I think as long as we manage the lifecycle and ensure we delete "stale" entries, then we will probably be fine regarding all the memory issues we've had in the past (and that you've helped fix 🙂 ).
checkpatch fails due to a typo in the commit message:
|
/test |
Seems that the Jenkins tests failed due to what seems to be a rebasing issue. Will rebase and re-run. |
7fdcb03
to
3ac9b0b
Compare
/test |
This pull request has been automatically marked as stale because it |
This pull request has been automatically marked as stale because it |
This pull request has been automatically marked as stale because it |
f9950f6
to
edf9613
Compare
Forgot about this since I thought #23429 mitigated it, but seems like that only conflicted with one of the changes. Pushed an updated version now |
edf9613
to
854769f
Compare
CI pointing out more places to remove
|
cf2e56f
to
7138f62
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.
One nit on the commit title / msg, is that we are not entirely removing the usage of the LRU, but simply avoiding it in certain cases, see https://github.com/cilium/cilium/pull/22584/files#r1063772535. I think we should clarify that because it can certainly cause confusion for future readers. Maybe an additional code comment on the LRU and non-LRU code paths to explicitly state why a code path uses one or the other.
Hmm. The commit message body is in the context of the title with the |
7138f62
to
f1f6ffe
Compare
Since we now have a separate reference counted cache storing compiled regexes, we no longer need the lru here. This will both make more space for other values in the cache, as well as making the huge regexes used in the dnsproxy available to gc when they are no longer used. The regex LRU is still being used elsewhere in the cilium codebase, where reusing compiled regexes makes sense, while reference counting is non-trivial. Signed-off-by: Odin Ugedal <ougedal@palantir.com> Signed-off-by: Odin Ugedal <odin@uged.al>
f1f6ffe
to
11a9206
Compare
/test |
Mind retesting this @christarazi ? Thanks |
/ci-e2e |
/ci-multicluster |
Since we now have a separate reference counted cache storing compiled regexes. This will both make more space for other values in the cache, as well as making the huge regexes used in the dnsproxy avaible to gc when they are no longer used.
Signed-off-by: Odin Ugedal ougedal@palantir.com
Fixes: #22241