On 3 different machines, all MEM% column items say 0%.
Hi, I've send a pr related with this one. (bug 207133)
This is still a bug and not related to 207133.
I'll work with the maintainer on this.
Created attachment 166956 [details] Fixes CPU% to be the same as top and ps. This patch makes htop CPU% output the same as top and ps output.
Created attachment 166957 [details] This hack addresses CPU% & MEM% problems. This hack addresses CPU% and MEM% issue.
A commit references this bug: Author: cy Date: Sun Feb 14 03:07:01 UTC 2016 New revision: 408842 URL: https://svnweb.freebsd.org/changeset/ports/408842 Log: Make CPU% display the same as ps and top do. MEM% displays 0.0. Fix that. PR: 207120 Changes: head/sysutils/htop/Makefile head/sysutils/htop/files/patch-freebsd__FreeBSDProcessList.c
Fixed.
I have created a pull-request for this upstream https://github.com/hishamhm/htop/pull/399 Expect that this will be imported
Mmm, I'm not sure, but after this, the CPU information seems off. on a 4 cores box, it never gets over 25%, and on my poudriere builder, which has 24 cores, the cpu utilisation never gets over 4%. It seems that the per-cpu information is divided by the number of CPU, or something.
I have no problem. Htop matches the output of top and systat (both in base). I'm running a dual core with two hyperthreads (four logical processors) at the moment. You can test by forking off a few of these: while :; do :; done & Do this for each processor, then compare with top and systat in base.
Created attachment 168310 [details] screenshot.png See this screenshot, it is a tmux split on the same box, as you can see, top -P (at the top) gives a very different result from htop (at the bottom).
Created attachment 168311 [details] screenshot2.png This one is from a 4 core box.
(In reply to Mathieu Arnold from comment #12) Pi@ just updated htop to 2.0.1. Does this fix it?
The last commit to htop broke it for me as well. My four core machine now shows 400% busy under htop while top and systat show 100%. 400% busy is consistent with how Linux reports CPU however it inconsistent with BSD.
Created attachment 168312 [details] screenshot3.png Ah, so, it went from individual cpus reporting l/<hw.ncpu> to individual cpus reporting l*<hw.ncpu> It'll end up being right, one day :-)
It worked correctly under htop version 1. Version 2 has been linuxified to the point where it's marginally useful on a BSD system.
Is this still relevant? Or is it fixed? (I have no problems with htop).
I think we can close it.
No, we cannot close this. htop has the same bahaviour as Linux top, not like FreeBSD top. CPU% on FreeBSD top, 100% is 100% of one logical processor (core or thread). Whereas Linux top 100% is 100% of all processors combined. Htop behaves as Linux top. This PR (my patch) makes htop behave like FreeBSD top.
Is it fixed now with https://svnweb.freebsd.org/ports?view=revision&revision=463618 ?
It doesn't look like it. Additionally it reports wait for I/O as zero. Wait for I/O is reported by Linux and Solaris but not FreeBSD as wait for I/O is included in idle in FreeBSD. As FreeBSD doesn't maintain this stat, it should be removed.
Except for wait for I/O the headers look correct as does a single process pegging one CPU on a two core, four thread CPU. Memory used is total garbage on -CURRENT probably due to PQ_LAUNDRY. (Though I never use just that to size a machine.) Ideally htop should report the same memory stats that FreeBSD top does. This would involve a little more involved patch, which should be submitted upline.
Thanks, (In reply to Cy Schubert from comment #22) > … Memory used is total garbage on -CURRENT … Does that sort of explain the non-100% total that's observed at <https://old.reddit.com/r/freebsd/comments/nlb7tq/-/gzmr4nf/?context=1>? The screenshot was of 13.0-RELEASE-p1.
(In reply to Mathieu Arnold from comment #12) How do you get that type of column, with 3.2.2? (I'm fairly familiar with F2 to setup, but I can't find what's pictured in your screenshot.)
Is this fixed by https://cgit.FreeBSD.org/ports/commit/?id=ef1b781fb1d88ba11cadc4f35bb398bea2378aef
Can anyone confirm or deny? :-)