On 05/18/2014 10:47 AM, Michael Tautschnig wrote: > 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...)
Hi Michael, Thank you for giving that a try. No argument about top not being a very portable great choice by upstream. I'll use /proc/meminfo for the Debian patch. It looks the same on linux, hurd, and kfreebsd, so it shouldn't be any *less* portable. Thank you for your help, tony
signature.asc
Description: OpenPGP digital signature
