Bug 207120 - sysutils/htop memory percentage column all 0%
Summary: sysutils/htop memory percentage column all 0%
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Kurt Jaeger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-11 22:24 UTC by synthmeat
Modified: 2018-05-20 18:28 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (gaod)


Attachments
Fixes CPU% to be the same as top and ps. (1.37 KB, patch)
2016-02-13 21:23 UTC, Cy Schubert
no flags Details | Diff
This hack addresses CPU% & MEM% problems. (2.32 KB, patch)
2016-02-13 22:07 UTC, Cy Schubert
no flags Details | Diff
screenshot.png (931.86 KB, image/png)
2016-03-16 23:51 UTC, Mathieu Arnold
no flags Details
screenshot2.png (830.26 KB, image/png)
2016-03-16 23:56 UTC, Mathieu Arnold
no flags Details
screenshot3.png (933.53 KB, image/png)
2016-03-17 01:58 UTC, Mathieu Arnold
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_committer 2016-02-12 20:51:06 UTC
This is still a bug and not related to 207133.
Comment 3 Cy Schubert freebsd_committer 2016-02-13 21:21:49 UTC
I'll work with the maintainer on this.
Comment 4 Cy Schubert freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 2016-02-14 03:08:36 UTC
Fixed.
Comment 8 Bernard Spil freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 w.schwarzenfeld freebsd_triage 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 freebsd_committer 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 w.schwarzenfeld freebsd_triage 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 freebsd_committer 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 freebsd_committer 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.