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

11–20 of 33 posts

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

#11

Post by cstrahan »

zx8080 wrote: post #9
jaggederest wrote: post #5

Earlier quoted context omitted.

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".

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...

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

#12

Post by acedTrex »

asdfman123 wrote: post #4

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.

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

#13

Post by debatem1 »

danudey wrote: post #3

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 inter…

Definitely not new in eBPF or LSMs in general.

Edit: link to the SELinux kernel Access Vector Cache (AVC): https://elixir.bootlin.com/linux/v3.4.64/source/security/sel...

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

#14

Post by jaggederest »

cstrahan wrote: post #11
zx8080 wrote: post #9

Earlier quoted context omitted.

No. The oldschool is "daemon".

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.

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

#15

Post by Brian_K_White »

zx8080 wrote: post #9
jaggederest wrote: post #5

Earlier quoted context omitted.

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".

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.

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

#16

Post by selcuka »

zx8080 wrote: post #9
jaggederest wrote: post #5

Earlier quoted context omitted.

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".

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

[1] https://scispace.com/pdf/an-introduction-to-software-agents-...

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

#18

Post by Allybag »

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.
Post reply on HN