memory/info test returns incorrect memory units

[Jeff Lane ]

Output run on server:
PASS: Difference is 2262204416 bytes (1.65%) and less than the 10% threshold.
 /proc/meminfo reports: 135176749056 kB
 dmi reports: 137438953472 kB

According to those numbers, that system has something like 125 TERABYTES of RAM.

Here's the output of meminfo on that system:
MemTotal: 132008544 kB
MemFree: 130181232 kB
Buffers: 19096 kB
Cached: 168916 kB
SwapCached: 0 kB
Active: 283764 kB
Inactive: 131080 kB
Active(anon): 227108 kB
Inactive(anon): 300 kB
Active(file): 56656 kB
Inactive(file): 130780 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 549800 kB
SwapFree: 549800 kB
Dirty: 508 kB
Writeback: 0 kB
AnonPages: 226016 kB
Mapped: 36528 kB
Shmem: 580 kB
Slab: 79916 kB
SReclaimable: 25004 kB
SUnreclaim: 54912 kB
KernelStack: 3328 kB
PageTables: 6660 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 66554072 kB
Committed_AS: 1045724 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 768640 kB
VmallocChunk: 34290811388 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 102400 kB
DirectMap2M: 4083712 kB
DirectMap1G: 130023424 kB

[Daniel Manrique (roadmr)]

The parser (checkbox/parsers/meminfo.py) multiplies the number taken from /proc/meminfo by 1024; thus, the parser returns *bytes* and not kB:

meminfo[key] = int(integer) * 1024

Then, the memory_compare script considers this is in kB already, hence the mismatch; we're off by a factor of 2^10:

print("\t/proc/meminfo reports:\t%s kB" % visible_memory, file=sys.stderr)

The dmi parser does the same, here's an instance of a memory module with the size reported in bytes:

path: /devices/virtual/dmi/id/device
category: DEVICE
vendor: Samsung
serial: 96FC8ED6
size: 2147483648
form: SODIMM

So at least memory_compare is comparing apples to apples, even if our apples' size is off by 1024 (yum, a 300-kg apple).

I think this just needs fixing the display in memory_compare script. I'd vote for displaying sizes in MB (those large kB numbers are awfully hard to visually parse), or maybe being smart enough to choose an appropriate unit (for this system with 132 GB, the numbers will also be somewhat awkward).

[Jeff Lane  (bladernr)]

On Wed, May 29, 2013 at 12:59 PM, Daniel Manrique
<email address hidden> wrote:
> The parser (checkbox/parsers/meminfo.py) multiplies the number taken
> from /proc/meminfo by 1024; thus, the parser returns *bytes* and not kB:
>
> meminfo[key] = int(integer) * 1024
>
> Then, the memory_compare script considers this is in kB already, hence
> the mismatch; we're off by a factor of 2^10:
>
> print("\t/proc/meminfo reports:\t%s kB" % visible_memory,
> file=sys.stderr)

I thought that may be the case but at the time didn't have time to do
any real investigation.

>
> The dmi parser does the same, here's an instance of a memory module with
> the size reported in bytes:
>
> path: /devices/virtual/dmi/id/device
> category: DEVICE
> vendor: Samsung
> serial: 96FC8ED6
> size: 2147483648
> form: SODIMM
>
>
> So at least memory_compare is comparing apples to apples, even if our apples' size is off by 1024 (yum, a 300-kg apple).
>
> I think this just needs fixing the display in memory_compare script. I'd
> vote for displaying sizes in MB (those large kB numbers are awfully hard
> to visually parse), or maybe being smart enough to choose an appropriate
> unit (for this system with 132 GB, the numbers will also be somewhat
> awkward).

Maybe the best thing to do, really, since the parsers are "back-end"
is have them return the common number (KB) and let the scripts accept
that and do what they will, be it using them as presented or
converting to MB, GB or whatever.

[Daniel Manrique (roadmr)]

Re-milestoning. Is this really in progress? :D

[Daniel Manrique (roadmr)]

I'll steal this bug for myself, heh