Date: Mon, 24 Aug 2015 09:00:01 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: George Spelvin <linux@horizon.com>, dave@sr71.net,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org,
        riel@redhat.com, rientjes@google.com, torvalds@linux-foundation.org
Subject: Re: [PATCH 3/3 v3] mm/vmalloc: Cache the vmalloc memory info
Message-ID: <20150824070001.GB13082@gmail.com>
References: <20150823060443.GA9882@gmail.com>
 <20150823064603.14050.qmail@ns.horizon.com>
 <20150823081750.GA28349@gmail.com>
 <87h9npwtx3.fsf@rasmusvillemoes.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87h9npwtx3.fsf@rasmusvillemoes.dk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1722
Lines: 41


* Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:

> I was curious why these fields were ever added to /proc/meminfo, and dug
> up this:
> 
> commit d262ee3ee6ba4f5f6125571d93d9d63191d2ef76
> Author: Andrew Morton <akpm@digeo.com>
> Date:   Sat Apr 12 12:59:04 2003 -0700
> 
>     [PATCH] vmalloc stats in /proc/meminfo
>     
>     From: Matt Porter <porter@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 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/