Rendered at 14:06:36 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
salviati 6 hours ago [-]
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.
danudey 15 hours ago [-]
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.
Eastmill 1 hours ago [-]
Simple memoization yields massive wins. Had similar experience with a hot loop, sometimes the basics are just magic.
brookman64k 8 hours ago [-]
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?
I'd also be interested in this, particularly in the "move" case, which requires no privileges and can also happen without the kernel being in the loop (e.g. on a different machine, in NFS).
If your calculated policy is a function of the entire path, you'd normally need to key the calculated policy by the entire path and its relevant properties (underlying inodes) as well, no?
There are path-based LSMs in the Linux kernel that do not employ such caching. If you found a solution for this which also works in the corner cases and results in speed-up in real life scenarios, I'd be interested :)
ComputerGuru 10 hours ago [-]
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?
bawolff 12 hours ago [-]
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.
nathannaveen 12 hours ago [-]
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.
mrbluecoat 15 hours ago [-]
So you highlight "Not AI Gen" but you call the solution "Agent"? :D
jaggederest 14 hours ago [-]
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.
zx8080 12 hours ago [-]
No. The oldschool is "daemon".
selcuka 11 hours ago [-]
Agent is an older term, apparently from the 1950s [1]:
> Alan Kay, a longtime proponent of agent technology, provides a thumbnail sketch tracing the more recent roots of software agents: “The idea of an agent originated with John McCarthy in the mid-1950’s, and the term was coined by Oliver G. Selfridge a few years later, when they were both at the Massachusetts Institute of Technology. They had in view a system that, when given a goal, could carry out the details of the appropriate computer operations and could ask for and receive advice, offered in human terms, when it was stuck. An agent would be a ‘soft robot’ living and doing its business within the computer’s world.” (Kay 1984).
Appreciate the references, I was the New Relic Ruby agent maintainer in 2010, as an additional reference. And we called it an agent, because it was hosted on the customer's infrastructure, but they didn't maintain or control it, we did. Regrettably no license to kill, and not much in the way of secrecy or gadgetry.
27183 9 hours ago [-]
> no license to kill, and not much in the way of secrecy or gadgetry
Insofar as you know.. there could be plenty of killer secrecy and gadgetry that was surreptitiously injected by your build/deployment/distribution systems ;)
jaggederest 9 hours ago [-]
it was ruby, so I did in fact know ;)
Edit: the customers, in some cases, did indeed run interpreters that were bad, but that's not my lookout! Buy me a fancy beverage and I'll tell you a story sometime
Brian_K_White 11 hours ago [-]
No, the oldschool is agent for those things for which it was agent.
An agent may or may not also be a daemon. It can be a cron job where the only daemon was cron not the agent, and the agent doesn't persist and isn't a daemon.
It can be purely ephemeral where the only daemon was ssh or http or any other other generic communication service that is merely how the agent was delivered.
Countless ordinary "things that run on a host and perform tasks for some other host" were always called agents. Some of those were also daemons, just as they were also programs.
Nagios, crowdstrike, chef, puppet, ansible, vmware/kvm/virtualbox, jenkins... etc all have a slave part that runs (usually in the form of a daemon) which is and always was called the agent.
youngtaff 8 hours ago [-]
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
yxhuvud 10 hours ago [-]
And uh, what happens if the active user permission changes?
nirmeetimthebes 11 hours ago [-]
[dead]
self_awareness 9 hours ago [-]
TL;DR - use in-memory cache instead of expensive database lookups on every iteration
aaron695 7 hours ago [-]
[dead]
asdfman123 14 hours ago [-]
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.
bawolff 12 hours ago [-]
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.
theowaway213456 13 hours ago [-]
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
acedTrex 12 hours ago [-]
I dont think an article title "dropping ebpf cpu cost with memoization" really needs to be accessible to a broad audience.
visarga 8 hours ago [-]
> 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
notpushkin 3 hours ago [-]
> I still like a few AI passes over it to tighten it up. LOL
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.
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.
Edit: link to the SELinux kernel Access Vector Cache (AVC): https://elixir.bootlin.com/linux/v3.4.64/source/security/sel...
If your calculated policy is a function of the entire path, you'd normally need to key the calculated policy by the entire path and its relevant properties (underlying inodes) as well, no?
There are path-based LSMs in the Linux kernel that do not employ such caching. If you found a solution for this which also works in the corner cases and results in speed-up in real life scenarios, I'd be interested :)
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.
> Alan Kay, a longtime proponent of agent technology, provides a thumbnail sketch tracing the more recent roots of software agents: “The idea of an agent originated with John McCarthy in the mid-1950’s, and the term was coined by Oliver G. Selfridge a few years later, when they were both at the Massachusetts Institute of Technology. They had in view a system that, when given a goal, could carry out the details of the appropriate computer operations and could ask for and receive advice, offered in human terms, when it was stuck. An agent would be a ‘soft robot’ living and doing its business within the computer’s world.” (Kay 1984).
[1] https://scispace.com/pdf/an-introduction-to-software-agents-...
https://www.eginnovations.com/blog/agentless-vs-agent-based-...
https://www.reddit.com/r/sysadmin/comments/js8h65/looking_fo...
https://www.ibm.com/docs/en/aix/7.2.0?topic=tools-performanc...
https://jolokia.org/agent/jvm.html
https://www.oracle.com/technical-resources/articles/javase/j...
Insofar as you know.. there could be plenty of killer secrecy and gadgetry that was surreptitiously injected by your build/deployment/distribution systems ;)
Edit: the customers, in some cases, did indeed run interpreters that were bad, but that's not my lookout! Buy me a fancy beverage and I'll tell you a story sometime
An agent may or may not also be a daemon. It can be a cron job where the only daemon was cron not the agent, and the agent doesn't persist and isn't a daemon.
It can be purely ephemeral where the only daemon was ssh or http or any other other generic communication service that is merely how the agent was delivered.
Countless ordinary "things that run on a host and perform tasks for some other host" were always called agents. Some of those were also daemons, just as they were also programs.
Nagios, crowdstrike, chef, puppet, ansible, vmware/kvm/virtualbox, jenkins... etc all have a slave part that runs (usually in the form of a daemon) which is and always was called the agent.
Makes the post a joy to read
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
Go ahead, it’s open source: https://github.com/bomfather/agent