Debian Wheezy, xfce4-systemload-plugin 1.1.1-1+b1, on a Dell Precision M4600 with 8GB RAM. The "mem" value reported by systemload is consistently wrong. The applet shows a green bar with a very low value. Hovering mouse over that I see: "1596MB of 7962MB used" At the same time, the output from "free" $ free -m total used free shared buffers cached Mem: 7962 7763 198 0 521 5557 -/+ buffers/cache: 1684 6277 Swap: 7627 0 7627 Do you see same? If so, how can I help. Do you require other info on my system to understand the problem? Could I just guess a few things? Here's some paste. $ uname -a Linux pjlap-124 3.4-trunk-amd64 #1 SMP Tue Jun 26 17:23:03 UTC 2012 x86_64 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz stepping : 7 microcode : 0x23 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5387.35 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz stepping : 7 microcode : 0x23 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5387.35 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz stepping : 7 microcode : 0x23 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5387.35 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz stepping : 7 microcode : 0x23 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5387.35 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: pauljohn@pjlap-124:proc$
hello paul, (In reply to comment #0) > The "mem" value reported by systemload is consistently wrong. The applet > shows a green bar with a very low value. Hovering mouse over that I see: > > "1596MB of 7962MB used" > > At the same time, the output from "free" > > $ free -m > total used free shared buffers cached > Mem: 7962 7763 198 0 521 5557 > -/+ buffers/cache: 1684 6277 > Swap: 7627 0 7627 > > Do you see same? If so, how can I help. the value reported by the plugin corresponds to this calculation: used = total - cached - buffers - free the values are read from /proc/meminfo, those values are also reused by the command free. can you show the first four lines from meminfo, and provide again the value reported by the plugin? for example: $ head -4 /proc/meminfo MemTotal: 2059664 kB MemFree: 64808 kB Buffers: 96288 kB Cached: 1394900 kB perhaps the tooltip is not being updated? does it actually change? you can try to launch or quit an application. regards, mike
Thanks. $ head -4 /proc/meminfo MemTotal: 8153228 kB MemFree: 291788 kB Buffers: 333900 kB Cached: 5675796 kB Same time, mem applet indicates: Memory: 1817MB of 7962MB used The values do change, they just appear incorrect IMHO I closed the Email client and it changed to Memory: 1710MB of 7962MB used At same time: $ head -4 /proc/meminfo MemTotal: 8153228 kB MemFree: 386788 kB Buffers: 334276 kB Cached: 5678272 kB Here's the top output for comparison top - 11:47:20 up 5 days, 1:37, 1 user, load average: 0.95, 1.08, 1.03 Tasks: 221 total, 2 running, 219 sleeping, 0 stopped, 0 zombie %Cpu(s): 4.7 us, 2.3 sy, 0.0 ni, 92.8 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st KiB Mem: 8153228 total, 7767120 used, 386108 free, 334296 buffers KiB Swap: 7811056 total, 1408 used, 7809648 free, 5678292 cached
$echo $(((8153228-386788-334276-5678272)/1024)) 1712 -> it matches the 1710 used you see. As for used/cached vs top/free -m, besides some rounding when dividing by 1024; if you look at the -/+ buffers/cache line in free -m it more or less matches the reported value. It all accounts to what you want to display, if you want to take the buffers/swap into account... displaying a "memory used" value is very empiric. The original developer of systemload decided to compute the value this way... If you take the values from top, and substract buffers and cached from 'mem used' you end up with the same value. $echo $(((7767120-5678292-334296)/1024)) 1713 So.. not really a bug ?
Not a bug, I hope everything was well explained.
*** Bug 10382 has been marked as a duplicate of this bug. ***