Hi Tony, [...] > That explains the problem. It looks like your system has 256GB on it,
Yes :-) > but the default for top is to display in KB, so the '+' (which indicates > truncation) is tripping up the class that parses the output. > > > KiB Mem: 26465643+total, 11191324 used, 25346510+free, 1385252 buffers > > KiB Swap: 14483046+total, 40240 used, 14479022+free. 7171196 cached Mem > ^ > > Currently, this test and class in general will fail on any system with > more 96GB on it. And it seems wrong to patch the code to just accept > the truncated value. I don't see a way to set the scaling factor from > the command-line invocation (and it introduces decimal points to the > output anyway). I don't have access to a system with that much memory > on it (none of the public porterboxes appear to have more than 32GB), > and am wondering if the -w (width) option will help. > > If you are willing, the output of the following on your build system > would helpful for creating a patch for large memory systems: > > top -n1 -b -w256 > [...] I did give this a try, but it has zero effect on the memory column, it seems this is a fixed width column! (Reducing -w to something ridiculous like -w20 does have the expected effect.) I'm afraid parsing the output of top is not going to get us anywhere here - why does it have to be top after all? Wouldn't /proc/meminfo be much easier anyway? (I don't see much portability with top after all...) Best, Michael
pgp_KOWjOhlHv.pgp
Description: PGP signature
