It would help if kernel provided process information in binary form instead of serializing it into text. Or even better to provide specific syscalls for it like on macOS, Windows, OpenBSD, Solaris and others.
> While I agree that it is _less_ efficient than some other ways, in what way is that _significant_?
This gets noticeable when every connected user/session runs the htop.
I don't know, but I don't see doing random reads from kernel memory as particularly sane API to get list of processes and procfs is several orders of magnitude cleaner solution.
This is not correct - /dev/kmem and similar are typically only readable by root. If what you say were correct, ps and friends wouldn't work for unprivileged users (unless they were setuid root, which they're not).
You can see a ps.c implementation here: https://searchcode.com/codesearch/view/29853364/
which uses kvm library: https://www.freebsd.org/cgi/man.cgi?query=kvm&sektion=3&apro...
> Or even better to provide specific syscalls for it like on macOS, Windows, OpenBSD, Solaris and others.
top manages to take 6% CPU on my Macbook.
Cointop  is one of these projects that comes to mind.
Unfortunately both the MBP and my current XPS 15 are unable to drive cool-retro-term on a 4k display with the CPU integrated graphics, and they both overheat and throttle if I use the nvidia graphics card :/
It's a really cool terminal though: https://github.com/Swordfish90/cool-retro-term
CPU wise, Intel defines their TDP as the average heat dissipation, but the CPU can boost higher than this. But from what I understand they tell manufactures to design to the TDP.
"NVIDIA GPUs htop like monitoring tool"
Well, it has "top" in the name. ^__~
I would say that jnettop is more similar to nethogs than htop...
Press S in htop and you can select to show i/o-related data, including number of bytes and number of operations in total and per second.
You will need to be root to look at most i/o related data.
(the other parts require subscription)
It used to be in the early 90s that Unix systems were quite frequently I/O bound; disks were slow and typically bottlenecked through one bus and lots of processes wanted disk access all the time. Swapping was also way more common. Load average is more or less a quick count of all processes that are either waiting on CPU or waiting on I/O. Either was likely in an old Unix system, so adding them all up was sensible.
In modern systems your workload is probably very specifically disk bound, or CPU bound, or network bound. It's much better to actually look at all three kinds of load separately. htop is a great tool for doing that! but the summary load average number is not so useful anymore.
Linux recently got an interface called Pressure Stall Information that lets you collect accurate measures of CPU, I/O and memory pressure.
- Horribly under-specced machine (8GB RAM) with way too many (~150) tabs open -> continuous swap stalls that last for minutes at a time and freeze the mouse cursor: 5-second load average of 12-20
- 6-year old Android phone doing tasks in the background, generally feeling more than adequately performant, and lukewarm enough that you aren't sure if it's your hand or the phone generating the warmth: load average of 12-13
- Building Linux with -j64 to see what would happen: 5-second load average of 0.97... 0.99... 49.40... 127.21... ^C^C^C^C^C^C^C^C^C 180.66... ^C^C^C^C^C^CCCCCCC^^^CCcccCCcCC 251.22... ^C^C^C^C^C^C ^C^C^C^C ^C^C^C ^C^C^C^C^C^C ^^^CCCCC^C^C^C (mouse finally moves a few pixels, terminal notices first ^C) 245.55... 220.00... 205.42... 198.94...
- Resuming from hibernation with 20GB of data already in swap: 0.21... 0.15... 0.10... 251.50... 280.12... 301.69... 362.22... 389.91... 402.40... 308.56... 297.21... 260.66... 254.99... (etc; this one takes a while)
> $ strace uptime 2>&1 | grep open
Instead, you should do `strace -e open uptime` to select that system call. Like Useless Use of Cat, this could be considered a Useless Use of Grep.
Edit: Heh, when I went back to continue reading the article this was mentioned on the following line. Oops :)
Meanwhile, strace's -e filter will find exact matches of syscalls that are named on the command line.
Obviously the author wants the second one, but it is hardly useless to grep. And, once you know how to use grep, you know how to do this sort of search for every program ever written. It is nice that strace has its own budget string matching built in... but knowing how strace works only tells you how strace works. Knowing how grep works lets you do this sort of thing to any program that outputs text.
(A lot of work has been done to try and make something as good as "strace -e" but generically; for example, Powershell's Select-Object cmdlet. I have never managed to get that to do anything useful, but they did manage to break grep, erm ... Select-String, in the process. Great work!)
You could always do things the quick-and-dirty way, but does that help you grow as a programmer? You could write Python code that looks like C, like many people do when they come from a C background, or you could learn how to write Pythonic code by reading the documentation and examples.
> Knowing how grep works lets you do this sort of thing to any program that outputs text.
It's worth noting that I could say the same about strace. Once you know strace, you could run it against any program that uses system calls, which by the way, is many. :-)
If you have filenames with newlines you may have other - less nasty - stuff too.
So you either get a reasonable answer in 1s (or 2s if you have short look at the output before counting). Or you spend 1h+ discussing requirements and carefully writing a program that gives a precise answer.
Things to consider:
- how to treat symlinks
- how to treat hardlinks
- what if files are added/removed to/from the directory tree while you scan
- how to react to missing read permissions
- is your regex on the whole path or just on the basename
As a real-world example for those who are curious, running mkdir twice yields errno 17, EEXIST, which is "File exists":
root@vbox:~# mkdir directory
root@vbox:~# mkdir directory
mkdir: cannot create directory ‘directory’: File exists
Speaking as someone who is using Unix-like systems since the days of Santa Cruz Operation and Linux on a 50 MB disk partition - not everything that is permissible is auspicious.
And most often that's because the permissions were too lax to begin with. That's what you get when a bunch of pot-smoking hippies (X) draw your OS specifications.
I avoid using even spaces in file names, for this specific reason.
(X) - and I say that in the best way possible, though some may be inclined to disagree.
"...he and brethren were attempting to make a small fortune for themselves by secreting away an item - a printed book - that was easy enough to get in 1640 but near impossible to get in Tristan's age, making it of great worth."
"So you're thieves and chancers," said I approvingly.
"No," he objected.
-- The Rise And Fall Of D.O.D.O. by Neal Stephenson and Nicole Galland
strace -e trace=process
$ strace uptime 2>&1 | grep open
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 3
$ strace -e open uptime
10:12:14 up 2 days, 18:52, 1 user, load average: 1.22, 1.30, 1.71
+++ exited with 0 +++
After digging in the documentation, I finally found something working:
$ strace -e trace=openat uptime
$ strace -e openat uptime
Is probably easier to remember. You can filter from there.
You can be a hero, too! I find this inspiring. It's nice to see such an accessible and pragmatic way of making a contribution to the community. My very first thought on seeing that was "I could do that!"
I found the "IO Activity time", percentage of time when IO is used, to be a really good indicator of IO load on machine level - neither io-op per second, neither bandwith tell much if you're already using up all available IO. Load does not help here, as number of processes doing IO influences "load" more.
Thanks again, mystery solved.
Besides being a great explanation of htop, I like the way this article captures the way I - far from a shell guru - tend to think when putting together a few steps in the terminal. And even then it shows that it pays to read the man page too!
Isn't this the famous kernel HZ? It was originally 100 (interrupts/second), but nowadays often 250 or 1000:
This is made more complex by the ability to configure the scheduler with high granularity, including the ability to schedule different processors and process groups with different schedulers (and the rules that govern how the schedulers can then preempt each other).
Btw. additional recommendation (especially when a lot of CPUs and/or disks are involved + you want to keep an eye on multiple things at once): nmon
Seeing the last page of htop's output after it exits is usually useful to me.