|Summary:||top Reports Incorrect Swap File Size|
|Product:||Base System||Reporter:||John <jlmales>|
|Component:||bin||Assignee:||freebsd-bugs mailing list <bugs>|
|Severity:||Affects Many People||CC:||marklmi26-fbsd, ota|
Description John 2019-08-23 05:12:26 UTC
Created attachment 206811 [details] Full examples of CLI results of top, htop, swapinfo top reports incorrectly swap file size of: "Swap: 30G Total". swapinfo correctly reports swap file size of: "/dev/ada0s1b 50331644 0 50331644 0%" htop correctly reports swap file size of: "Swp [<snip blanks> 0K/48.0G]" top -v top: version 3.5beta12 htop --version htop 2.2.0 - (C) 2004-2019 Hisham Muhammad Released under the GNU GPL. uname -a FreeBSD h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd 11.3-STABLE FreeBSD 11.3-STABLE #0 r349903: Thu Jul 11 16:13:47 UTC 2019 email@example.com:/usr/obj/usr/src/sys/GENERIC amd64
Comment 1 ota 2019-09-16 01:41:52 UTC
How much physical memory do you have? I recall there is a limit on how much swap space can be used. In other words, you may not be able to use 50GB swap device/file (based on the size of physical memory.) Top may report available size instead of device size...
Comment 2 John 2019-09-16 05:25:38 UTC
(In reply to ota from comment #1) As noted in initial bug report htop and swapinfo both report the correct swap file size. top does not report the correct swap file size at something less than what is allocated for swap file size. That is the issue. Further the amount of RAM installed does not determine what the reported size of the swap file or sum of multiple swap files is. Both swapinfo and htop report the correct swap file size. top does not report the correct swap file size. Therefore the issue is top failing to correctly report the swap file size that has no bearing on the amount of ram installed. Swap file was sized during FreeBSD install to accommodate short term and long term RAM upgrades. In theory there is no restriction on RAM size as function to determine swap file size that can be allocated for any OS. This includes IBM Mainframes that have used Virtual Memory since the 1970s and therefore have used swap files as a result since the 1970s. In practice there may be limits simply due to extent of swap file/RAM page thrashing/faults per second an OS can incur that is system/application specific mix/active/activity and/or disk space wasted that will not be used for swap or not used for swap much of the time. System planning and testing enable the swap file size and usage characterizations to be calculated. The amount of swap space defined during an install does not always mean the OS calculated swap file size is taken as at time of install. The OS install calculated default swap file size cannot take into account future system upgrades, nor characterization usage patterns of system/applications of the swap file. The amount of RAM currently install on the system is provided in the information when the initial bug report was made. I have worked with Virtual Memory based OSs since the 1970s. I have lots of experience with Virtual Memory and swap file space allocations/characterizations on IBM Mainframes as well as Unix since the early 1990s (SunOS, AIX, System V, Linux, et al) based systems and some Unix experience as early as the mid 1970s.
Comment 3 Mark Millard 2019-09-16 08:42:44 UTC
(In reply to John from comment #0) https://svnweb.freebsd.org/base/head/usr.bin/top/top.c?revision=343957&view=markup&pathrev=349235 shows: 313 case 'v': /* show version number */ 314 errx(0, "version FreeBSD"); 315 break; and when I try top -v that is what it shows: # top -v top: version FreeBSD This traces back to: Revision 333901 - (view) (download) (annotate) - [select for diffs] Modified Sat May 19 23:04:42 2018 UTC (15 months, 4 weeks ago) by eadler File length: 27840 byte(s) Diff to previous 333900 top(1): unconditionally provide 'FreeBSD' as a version So your version of top is from before -r333901 despite your uname -a showing -r349903 . You may need to update more things to really be more modern than they actually are.