pcp: Linux memory classes carry the labels of the wrong enum slots

[ravi-arnan]

pcp/Platform.c builds Linux_memoryClasses[] with designated initializers keyed on the enum in pcp/PCPMachine.h, but the label sequence looks like it was transcribed positionally from linux/Platform.c, whose enum orders the same six names differently:

index	linux/Platform.c	pcp/PCPMachine.h
0	USED	USED
1	SHARED	SHARED
2	COMPRESSED	BUFFERS
3	BUFFERS	CACHE
4	CACHE	COMPRESSED
5	AVAILABLE	AVAILABLE

Keying by pcp's own names while carrying linux's label order rotates three labels off the values they sit on:

slot	value it holds	label it carries
[MEMORY_CLASS_BUFFERS] = 2	PCP_MEM_BUFFERS (pcp/PCPMachine.c:74)	"compressed"
[MEMORY_CLASS_CACHE] = 3	PCP_MEM_CACHED + sreclaimable - shared (pcp/PCPMachine.c:79)	"buffers"
[MEMORY_CLASS_COMPRESSED] = 4	zswap.usedZswapComp (pcp/Platform.c:623)	"cache"

So against a Linux host, pcp-htop prints the buffers figure as compressed, the page cache figure as buffers, and zswap's compressed pool as cache. Platform_setMemoryValues() at pcp/Platform.c:605-625 copies each memValue[] into the same slot, so the values themselves are fine; only the names attached to them are wrong.

The flags are off in the same place

Comparing the two tables entry by entry, countsAsCache is false in pcp for the two slots where linux/Platform.c has it true:

slot	linux	pcp
buffers	countsAsUsed=false, countsAsCache=true	countsAsUsed=false, countsAsCache=false
cache	countsAsUsed=false, countsAsCache=true	countsAsUsed=false, countsAsCache=false

MemoryMeter_updateValues() sets any class with neither flag to NAN in bar and graph mode:

if ((countsAsCache && !settings->showCachedMemory) || !(countsAsCache || countsAsUsed))
   this->values[memoryClassIdx] = NAN;

so on a Linux host the two cache figures are not drawn in the bar at all, and showCachedMemory has nothing left to toggle there. Text mode still prints them, under the rotated labels above.

How I checked, and what I did not check

This is from reading pcp/Platform.c, pcp/PCPMachine.c, pcp/PCPMachine.h, linux/Platform.c and MemoryMeter.c at 6f33ddd, tracing each index from the metric that fills it to the label that names it. I do not have a PCP setup, so I have not run pcp-htop against a live pmcd to see it on screen, and I would not want the report taken as if I had.

The Darwin table two entries down (Darwin_memoryClasses[], pcp/Platform.c:89-96) is keyed consistently with its own enum and does not have this problem, though its countsAsUsed flags differ from darwin/Platform.c (speculative and inactive are true there and false in the native platform file), which may be deliberate and is a separate question.

Happy to send a patch, either re-keying the initializers or reordering the pcp enum to match the native one, whichever you would prefer. Noticed this while working on #2073.

[natoscott]

Thanks @ravi-arnan I'll take a look, sounds like a good catch - nice one.

so I have not run pcp-htop against a live pmcd to see it on screen

You can just run pcp-htop without pmcd FWIW, it falls back to using shared libraries.