Message-Id: <55893958020000A10001ADA2@gwsmtp1.uni-regensburg.de>
Date: Tue, 23 Jun 2015 10:47:52 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <linux-kernel@vger.kernel.org>
Subject: Formatting of /proc/meminfo
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1599
Lines: 43

Hi!

My eyes just discovered this mis-alignment for x86_64 machines:
--- 
# cat /proc/meminfo
MemTotal:       81366016 kB
MemFree:        36484504 kB
Buffers:         1018764 kB
Cached:         38230264 kB
[...]
VmallocTotal:   34359738367 kB
VmallocUsed:       92792 kB
VmallocChunk:   34359544432 kB
HardwareCorrupted:     0 kB
DirectMap4k:    132623356 kB
DirectMap2M:           0 kB
---

It seems the very big numbers for "Vmalloc" are OK, so I suggest to update the formatting. The current code looks like this (/usr/src/linux/fs/proc/meminfo.c):
---
        seq_printf(m,
                "MemTotal:       %8lu kB\n"
                "MemFree:        %8lu kB\n"
                "Buffers:        %8lu kB\n"
[...]
---

So the field should be widened by three digits at least (%11lu kB). Maybe one could make the field width variable, depending on 32/64 bit (it would look like a waste on 32 bit platforms).

Maybe the code would be friendlier to changes if there was one seq_printf() per value. Then one could use something like
seq_printf(m, "%-16s%8lu kB\n", "MemTotal:", K(i.totalram))
instead, I guess... You could put the format (%-16s%8lu kB\n) in a constant also, allowing a change at one point to affect every item...
Probably gcc will optimize the code anyway, so there won't be much difference regarding performance.

Regards,
Ulrich Windl


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/