* Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote:
> I was curious why these fields were ever added to /proc/meminfo, and dug
> up this:
>
> commit d262ee3ee6ba4f5f6125571d93d9d63191d2ef76
> Author: Andrew Morton <a...@digeo.com>
> Date: Sat Apr 12 12:59:04 2003 -0700
>
> [PATCH] vmalloc stats in /proc/meminfo
>
> From: Matt Porter <por...@cox.net>
>
> There was a thread a while back on lkml where Dave Hansen proposed this
> simple vmalloc usage reporting patch. The thread pretty much died out as
> most people seemed focused on what VM loading type bugs it could solve. I
> had posted that this type of information was really valuable in debugging
> embedded Linux board ports. A common example is where people do arch
> specific setup that limits there vmalloc space and then they find modules
> won't load. ;) Having the Vmalloc* info readily available is real useful
> in
> helping folks to fix their kernel ports.
>
> That thread is at <http://thread.gmane.org/gmane.linux.kernel/53360>.
>
> [Maybe one could just remove the fields and see if anybody actually
> notices/cares any longer. Or, if they are only used by kernel
> developers, put them in their own file.]
So instead of removing the fields (which I'm quite sure is an ABI breaker as it
could break less robust /proc/meminfo parsers and scripts), we could just
report
'0' all the time - and have the real info somewhere else?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
