Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

nathannaveen.dev

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

#21

Post by 27183 »

jaggederest wrote: post #14
cstrahan wrote: post #11

Earlier quoted context omitted.

Agent is also a long established term: 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...

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.

> 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 ;)

Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

#22

Post by jaggederest »

27183 wrote: post #21
jaggederest wrote: post #14

Earlier quoted context omitted.

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.

> 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 ;)

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

Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

#26

Post by gnoack »

brookman64k wrote: post #24

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 :)

Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

#29

Post by salviati »

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.

Re: Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

#30

Post by psd1 »

brookman64k wrote: post #24

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?

Link with the answers: https://nathannaveen.dev/posts/dropping-ebpf-cpu-cost-by-90/
Post reply on HN