Gathering multiple system parameters in a single call

htop -d 10 , which gives me a nice, reliable view of what my system is doing, consumes 12-15% CPU. htop -d 1, which gives a great picture of what my computer is up to that moment, goes up to 50-60% CPU. 12-15% may not sound like a lot, but its the highest or 2nd highest consumer most of the time. This is on a system with two web browsers with well over 100 tabs open, as well as several other apps (some in python) running nearly constantly. Having my performance monitoring tool eat up more CPU than Firefox's 117 tabs in 3 windows is a little bit sad.

> He noted that an lsof on his laptop did not take an inordinate amount of time, so the performance argument does not really make sense to him.

I should be clear that the machine I am writing this on (and running these tests on) is running in battery mode: cpu frequencies are locked at 800 mHz, everything in "extreme power save mode", etc. However, despite running this command thrice to ensure everything was nice and warm in the caches, I still got these results:

time lsof > /dev/null
real 0m29.248s
user 0m16.245s
sys 0m12.842s

This might not be 'inordinate', but it's certainly significant. Even if we assume that every last moment of the 12 seconds spent on system calls is vitally needed and cannot be optimized by this new call, what exactly is being done during the 16 seconds in userspace? How much of that time amounts to "parse what the kernel gave us"?

This isn't really a matter of user-facing performance for me: rather, it's a question of power efficiency. If I leave htop running in the background for a while, that shouldn't harm my battery life substantially. Performance monitoring tools in userspace are very common: think of how many there are running in the world right now. If we make all of them twice as fast, we will save megawatts of power. Using the standard "oh, but tools won't use it at first" argument seems pretty silly to me: tools can detect the availability of system calls, and further, that argument applies to every possible bit of functionality: why aren't we hearing that objection to argue that the performance gains of, say, io-uring are irrelevant? As for attack surface, this interface is very easy to fuzz, and doesn't need to be sophisticated or heavily optimized. Compared to what it's replacing (a confused mix of interfaces developed over decades), I think it's very probable that the reduced attack surface in 10 years when distros can start configuring out the IOCTLs far exceeds that added by this interface.