|Summary:||sysutils/htop memory percentage column all 0%|
|Product:||Ports & Packages||Reporter:||synthmeat <synthmeat>|
|Component:||Individual Port(s)||Assignee:||Kurt Jaeger <pi>|
|Severity:||Affects Some People||CC:||brnrd, cy, eadler, gaod, mat, w.schwarzenfeld|
Description synthmeat 2016-02-11 22:24:53 UTC
On 3 different machines, all MEM% column items say 0%.
Comment 1 Hung-Yi Chen 2016-02-12 17:03:14 UTC
Hi, I've send a pr related with this one. (bug 207133)
Comment 2 Cy Schubert 2016-02-12 20:51:06 UTC
This is still a bug and not related to 207133.
Comment 3 Cy Schubert 2016-02-13 21:21:49 UTC
I'll work with the maintainer on this.
Comment 4 Cy Schubert 2016-02-13 21:23:27 UTC
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.
Comment 5 Cy Schubert 2016-02-13 22:07:42 UTC
Created attachment 166957 [details] This hack addresses CPU% & MEM% problems. This hack addresses CPU% and MEM% issue.
Comment 6 commit-hook 2016-02-14 03:07:44 UTC
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
Comment 7 Cy Schubert 2016-02-14 03:08:36 UTC
Comment 8 Bernard Spil 2016-02-14 20:55:37 UTC
I have created a pull-request for this upstream https://github.com/hishamhm/htop/pull/399 Expect that this will be imported
Comment 9 Mathieu Arnold 2016-03-15 01:32:37 UTC
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.
Comment 10 Cy Schubert 2016-03-15 03:21:43 UTC
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.
Comment 11 Mathieu Arnold 2016-03-16 23:51:15 UTC
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).
Comment 12 Mathieu Arnold 2016-03-16 23:56:41 UTC
Created attachment 168311 [details] screenshot2.png This one is from a 4 core box.
Comment 13 Cy Schubert 2016-03-17 00:12:42 UTC
(In reply to Mathieu Arnold from comment #12) Pi@ just updated htop to 2.0.1. Does this fix it?
Comment 14 Cy Schubert 2016-03-17 00:29:06 UTC
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.
Comment 15 Mathieu Arnold 2016-03-17 01:58:30 UTC
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 :-)
Comment 16 Cy Schubert 2016-03-17 05:10:33 UTC
It worked correctly under htop version 1. Version 2 has been linuxified to the point where it's marginally useful on a BSD system.
Comment 17 Walter Schwarzenfeld 2018-01-13 06:14:22 UTC
Is this still relevant? Or is it fixed? (I have no problems with htop).
Comment 18 Hung-Yi Chen 2018-01-14 03:26:58 UTC
I think we can close it.
Comment 19 Cy Schubert 2018-01-14 04:54:51 UTC
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.
Comment 20 Walter Schwarzenfeld 2018-03-05 19:18:21 UTC
Is it fixed now with https://svnweb.freebsd.org/ports?view=revision&revision=463618 ?
Comment 21 Cy Schubert 2018-03-05 20:38:17 UTC
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.
Comment 22 Cy Schubert 2018-03-05 20:51:40 UTC
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.