alt.hn

7/4/2026 at 12:00:57 PM

Explanation of everything you can see in htop/top on Linux (2019)

 https://peteris.rocks/blog/htop/

by theanonymousone

7/4/2026 at 2:31:43 PM

I've relatively recently migrated over to using btop[0], and it's the kind of modern interface, useful and informative, that I needed.

As others mention it - it seems to shows the Watts used as well :) (and network, and GPU, and disks,....)

[0]: https://github.com/aristocratos/btop

by imrehg

7/4/2026 at 2:53:38 PM

Yup, btop zealot here, it even replaced iStatMenu on my brand new MacBook ..

by MomsAVoxell

7/4/2026 at 3:59:13 PM

Oh wow, now I gotta check it out.

by NetOpWibby

7/4/2026 at 6:34:21 PM

Same. Btop is the best

by zackify

7/4/2026 at 2:30:33 PM

2 Settings I change on every htop which makes a HUGE difference.

1. I disable user threads. Those mostly just clutter up the htop view while providing no useful information.

2. I enable the process tree view. Very frequently, where a process comes from is much more important than other information. It also lets you see and track things like a compiler process which is eating through a bunch of files.

IMO, both these things should be the default behavior of htop.

by cogman10

7/4/2026 at 3:43:12 PM

I like the process tree view, but it stops the dynamic updates and reordering of process list.

by zekrioca

7/4/2026 at 4:37:59 PM

I appreciate the note on virtual memory not being reliable. This is what Windows task manager reports by default and it's terrible. Resident size is the most reliable metric. Anything else can be wrongfully inflated by things like harmless memory mapped files that won't actually hurt anything. eg. memory map 2GB of logfiles, it'll only be paged in if reading that portion of the logfile so isn't really using memory but users look at the processes and claim "OMG why does this app use so much memory". It doesn't. It uses very little. You're reading the memory usage wrong. Chrome actually had this problem for a while and they moved away from using memory mapped files. Not because memory mapped files are a bad thing but because users will read the memory usage and go crazy over what they see even though it's not really using that much actual physical memory.

There's actually guides out there on the web that tell people judge usage by virtual memory allocated too :(. At least this article gets it right :).

by AnotherGoodName

7/4/2026 at 7:54:35 PM

> Resident size is the most reliable metric

Actually, Proportional Set Size is more accurate than RSS. See: https://en.wikipedia.org/wiki/Proportional_set_size

by d3Xt3r

7/4/2026 at 8:11:32 PM

`procs display` (mentioned elsethread https://news.ycombinator.com/item?id=48788167 ) supports PSS via its %M format code.

One issue with that relative to RSS is permissions. Historically, all procs could see the RSS used by procs of all other users (at least if they could see the PIDs at all). So, RSS requires no special permissions, but the Linux kernel team decided PSS should not be as promiscuous for whatever reasons (I didn't do a deep dive). So, I'm always having to do (the equivalent of) `sudo pu`.

by cb321

7/4/2026 at 7:28:49 PM

> This is what Windows task manager reports

Just to clarify, Windows Task Manager uses Private Working Set by default for process memory usage which does NOT include shared pages with other processes such as libraries or memory mapped files (hence the name “private”). It only shows the memory that maps to privately allocated physical memory per process. It’s probably closer to Resident Set on Unix.

You probably meant the memory usage in performance tab but I wanted to clarify in case people mistake it for all memory usage fields.

by sedatk

7/4/2026 at 5:19:19 PM

If you use memory-mapped files, cached pages count towards the resident set size of your process. If you use ordinary file I/O, they don't. That behavior has amusing consequences in HPC clusters that monitor the memory usage of each job and kill them if they use more memory than they requested.

by jltsiren

7/4/2026 at 2:15:23 PM

Anyone else feel as if HN is healing? I hope this isn't the walking-ghost era of HN.

by fractorial

7/4/2026 at 2:25:23 PM

3 AI related articles on the front page, but one is busting slop. I'm hopeful.

by conqrr

7/4/2026 at 4:05:00 PM

When I read stuff like this, I come to the realization that even after daily driving Linux for 20+ years I still barely utilize its full potential. Great article.

by WD-42

7/4/2026 at 2:23:10 PM

For top if you use the > character it will sort by memory usage. I use that sometimes to figure out why my host is becoming laggy. Also you'll see swapd is taking up CPU.

by thijson

7/4/2026 at 4:46:41 PM

I prefer using the more memory friendly M (uppercase) for memory and P (uppercase) for CPU

by yomismoaqui

7/4/2026 at 7:27:43 PM

A different usage paradigm from *top that I have come to like better is to do differential ps-like reports and system-wide (like vmstat) reports which leaves everything in your terminal scrollback buffer as in: https://github.com/c-blake/procs { written in the uncommonly efficient, expressive Nim programming language }.

by cb321

7/4/2026 at 5:00:31 PM

For the ones that don't know "nmon", have a look at it as well! (press "h" to see the list of available monitors - press it again to make it go away, press "q" to quit)

https://nmon.sourceforge.io/pmwiki.php

Especially disk throughput and I/O (keys "d" & "D") can be very useful.

by zepearl

7/4/2026 at 7:03:16 PM

very useful tool. I install it on every machine where I have control. I appreciate the "Wide" CPU usage graph, that can handle huge core counts easily

by Zardoz84

7/4/2026 at 2:15:01 PM

I've had this bookmarked since 2016, and have referred to it many times over the years.

by wyclif

7/4/2026 at 2:14:42 PM

This is really good!

I use htop often but pretty much only use it to find pid or cpu-culprits, and never really understood the rest.

by TheChaplain

7/4/2026 at 2:15:54 PM

For pid I find pgrep to be the better suited tool

by bwnkl

7/4/2026 at 4:28:51 PM

Very interesting topic,Cool.

by love0972

7/4/2026 at 2:53:02 PM

s/htop/btop/

You'll be glad you did.

by MomsAVoxell

7/4/2026 at 6:56:30 PM

What's so good about btop? I personally can't stand its interface, I don't need bells and whistles in my terminal.

by allarm

7/4/2026 at 2:26:10 PM

[flagged]

by myshapeprotocol

7/4/2026 at 2:29:41 PM

A bit silly that you can see a load average but not the amount of Watts used by your system.

by amelius

7/4/2026 at 2:30:52 PM

Nowadays most of my processing happens on the GPU, so htop/top better evolve or become mostly irrelevant because a tool that will support both CPU __and__ GPU will replace it.

by amelius

7/4/2026 at 2:50:22 PM

Irrelevant for you does not mean irrelevant for others

by FpUser

7/4/2026 at 2:57:08 PM

Nails and hammers are great but most of us have moved on to screws and screwdrivers.

What good does it do to stick your head in the sand?

CPUs are great for orchestrating work, GPUs are great for actually doing the work.

by amelius

7/4/2026 at 6:45:28 PM

Screws have been around for about 3 millennia at this point. They have patently failed to obviate the use of nails. So by this analogy we can expect the 'Only GPUs do the work.' believers to be still promising this, any day now, about three thousand years hence. (-:

by JdeBP

7/4/2026 at 4:14:04 PM

>CPUs are great for orchestrating work

Right, and wouldn't it be really nice if we could check on our orchestrators to make sure their not bottlenecking ops?

"How come we can fully load the GPUs?" "Idk boss, amelius said htop et al were irrelevant so we can't really investigate"

by goodmythical

7/4/2026 at 4:02:20 PM

Did you write this comment using your gpu?

by WD-42

7/4/2026 at 3:05:23 PM

>"What good does it do to stick your head in the sand?"

Get the fuck out. I do write for GPU as well. One does not replace the other.

by FpUser

7/4/2026 at 3:45:49 PM

For high performance work, gpus have replaced cpus a long time ago.

by justthetop

7/4/2026 at 7:32:52 PM

There is plenty of "high performance work" that still requires CPUs.

by kergonath

7/4/2026 at 4:17:28 PM

Not for all definitions of HPC, though.

No one's doing database management on GPUs. No one's scraping data on GPUs. Can't run VMs on GPUs. Can't run web servers on GPU...

by goodmythical

7/4/2026 at 6:52:01 PM

It is sunny in my backyard now. Must be sunny everywhere else

by FpUser

7/4/2026 at 3:44:28 PM

Stupidest comment ever.

by zekrioca

7/4/2026 at 4:31:44 PM

[flagged]

by amelius

7/4/2026 at 3:55:47 PM

> Nowadays most of my processing happens on the GPU, so htop/top better evolve or become mostly irrelevant

If you’re a 3D rendering designer, an ML engineer or a crypto bro, then sure.

Here are the common workloads (for the average SWE on HN) that use CPU/RAM:

  - compilation/builds
  - language servers and IDEs
  - test suites
  - local containers
  - local databases
  - node tooling
  - browsers
  - data processing
  - compression and encryption
  - searching/indexing
Ok sure, top/htop is totally irrelevant now /s

by sevg

7/4/2026 at 7:09:48 PM

And your browser for instance might crash, if it runs out of gpu memory, which will surprise you if you only look for cpu/ram.

(Happened to me)

by lukan