From: Dave Jones <dsj@fb.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Shaohua Li <shli@fb.com>
Subject: Re: mm: remove vmalloc info from /proc/meminfo
Date: Mon, 2 Nov 2015 15:10:22 -0500 [thread overview]
Message-ID: <20151102201021.GA14806@fb.com> (raw)
In-Reply-To: <CA+55aFyWSAQE6pw2z0+QCuN=ckWv4QdzXuGyf+4VnUdUirOdWQ@mail.gmail.com>
On Mon, Nov 02, 2015 at 11:29:15AM -0800, Linus Torvalds wrote:
> On Mon, Nov 2, 2015 at 10:36 AM, Dave Jones <dsj@fb.com> wrote:
> > Reading /proc/meminfo is really slow, as it requires recomputing the
> > vmalloc data every time, which is a lot of work, when most (all?)
> > consumers of meminfo don't even care about those statistics.
>
> Ahh. My version of this patch (which I actually committed yesterday,
> since I remembered - will wonders never cease?) leaves the fields
> around in the /proc/meminfo file, but just makes the values be zero.
> It also removes the actual function to compute the data that nobody
> uses any more.
>
> I agree that we can eventually look at even removing the fields
> entirely, but that's much more likely to break things. I can imagine
> system tools that just root around for values, and break and complain
> when they don't exist, even if all they do is report them (rather than
> actually *use* them for anythign).
>
> I guess I should just push out my tree. I didn't want to keep people
> from testing plain 4.3, so I didn't push out yesterday.
>
> Can you test what is now (where "now" means "it might take a minute or
> two to mirror out") in my git repo?
That looks like it'll do the job just as well yeah, and I suppose is
a touch more conservative than my "burn it all down" approach.
Dave
prev parent reply other threads:[~2015-11-02 20:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-02 18:36 mm: remove vmalloc info from /proc/meminfo Dave Jones
2015-11-02 19:29 ` Linus Torvalds
2015-11-02 20:10 ` Dave Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151102201021.GA14806@fb.com \
--to=dsj@fb.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shli@fb.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.