Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
1–10 of 33 posts
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#2So you highlight "Not AI Gen" but you call the solution "Agent"? :D
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#3Very 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.
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#4I 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.
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#5So 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.
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#6I 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.
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
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#7I 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.
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.
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#8Umm, 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.
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#9So 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.
No. The oldschool is "daemon".
Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
#10Umm, 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.