Memoization trades compute time for memory: you reduce CPU cost by 90% _at the cost_ of some memory. The author measured one, but it doesn't look like they measured the other.

It's an important detail to take into account. I'm sure this optimization makes sense, and the size of additional memory is not that big, but I believe it's good to "measure, not assume" as some load bearing model might say.

Very confused by the article. Is memoization new to the eBPF world? Did the author only just learn about it and wanted to use it?

In reality, the article is about correctly caching a path:policy mapping while working within the limitations of eBPF and Linux filesystem semantics. If you read the article in that context rather than wondering 'what is new and interesting about memoization in eBPF?' it's a lot more interesting.

I probably would have titled this 'Calculating cache keys for filesystem paths in eBPF' or something, since that's the cool and interesting problem that was solved.

Seems like the 90% faster case is opening the same exact file every single time, which seems like a not super standard use case that will benefit the most from this caching. On an example where you never open the same file twice this will presumably be slightly slower than before, as you’re doing the same thing but writing to a cache. So you can make the headline “Drop performance cost by 90%!” or “Modestly increase performance cost” and be correct but I don’t think either is really a reasonable description of the change.

How is the cache invalidated when: - The permissions change? - Directories are moved? - Hard-links are added? - Things are deleted? Also: Is the cache limited in size?

How do your path-only rules handle the many approaches for loading a file but making it appear to have a different path, such as bind mounts for one example?

Simple memoization yields massive wins. Had similar experience with a hot loop, sometimes the basics are just magic.

OT but… it’s nice to see someone use a legible font with good character height and line spacing

Makes the post a joy to read

So you highlight "Not AI Gen" but you call the solution "Agent"? :D

Agent is an old school way to say "constantly running daemon to accomplish some specific purpose", as someone who wrote a lot of performance monitoring agents. AI is using the term appropriately, but I think assuming it's always AI-first is slightly tragic.

Naming's the least of it. "Agent" to me means one more daemon on every host that I get paged about. Memoizing in the monitoring path means stale cache bugs, and good luck debugging those at 3am.

Umm, wouldn't this break if you moved a directory that is somewhere up the path? Seems like a security issue if you cache what policy applies but the policy could change by user action.

Hey, author here, that is a great catch, thanks for pointing it out! If we are protecting a directory, then only people with access will be able to move the dir, so we are assuming that they don’t move (or rename) the directory maliciously. And, if we aren’t trying to protect the directory, then it doesn’t really mater to our protection whether that directory is moved.

Additionally, we are thinking of evicting the inode associated with the directory from the cache if a directory is moved. Doing this would probably catch a ton of edge cases and make it simpler.

And uh, what happens if the active user permission changes?

TL;DR - use in-memory cache instead of expensive database lookups on every iteration

I don't know what any of these acronyms mean. With just a little more explanation the article could be accessible to a wider developer audience.

I dont think an article title "dropping ebpf cpu cost with memoization" really needs to be accessible to a broad audience.

Yeah, anyone who's run bpftrace or Cilium in prod already knows the pain. Per-event map lookups and stack unwinding add up fast. Memoizing the stack walk is the obvious win, though the gotcha I hit was stale cache entries when pids get reused.

At some point, i feel like a tech article written to a tech audience has the right to assume certain technical knowledge. eBPF is not an obscure technology in the linux world, and its impossible to make your article target everyone while still being a good article.

Do yourself a favor and look up eBPF - it's incredibly powerful and cool tech. Basically lets you write scripts that run inside the kernel

> Not AI Gen

I am not sure how to react ... of course good thing it's human-gen, but I still like a few AI passes over it to tighten it up. LOL

> I still like a few AI passes over it to tighten it up. LOL

Go ahead, it’s open source: https://github.com/bomfather/agent

I'd push back on that. The "tightening" pass is exactly why everything reads the same now. Rough edges and odd phrasing are how you can tell a person wrote it. Ship the slightly clumsy version, I'll take it over the polished one every time.

Keying verdicts on path strings is already the classic AppArmor-style weakness, compared with inode or label-based checks. Caching on top of that probably widens the window between check and use, though I haven't seen anyone measure how much in practice. Curious whether the author considered it.