From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Bart Van Assche <bart.vanassche@gmail.com>
Cc: Albert Cahalan <acahalan@cs.uml.edu>,
linux-mm <linux-mm@kvack.org>,
procps-feedback@lists.sf.net
Subject: Re: [feedback] procps and new kernel fields
Date: Tue, 14 Apr 2009 11:35:24 -0700 [thread overview]
Message-ID: <1239734124.32604.100.camel@nimitz> (raw)
In-Reply-To: <e2e108260904070602p61b0be4fpc257f850b004c49f@mail.gmail.com>
On Tue, 2009-04-07 at 15:02 +0200, Bart Van Assche wrote:
> On Tue, Apr 7, 2009 at 6:40 AM, Albert Cahalan <acahalan@cs.uml.edu> wrote:
> > On Mon, Apr 6, 2009 at 5:55 PM, Dave Hansen <dave@linux.vnet.ibm.com> wrote:
> >> Novell has integrated that patch into procps
> >...
> >> The most worrisome side-effect of this change to me is that we can no
> >> longer run vmstat or free on two machines and compare their output.
> >
> > Right. Vendors never consier that. They then expect upstream
> > to accept and support their hack until the end of time.
>
> The patch that was integrated by this vendor in their procps package
> was posted on a public mailing list more than a year ago. It would
> have helped if someone would have commented earlier on that patch.
We suck. :)
> >> We could also add some information which is in
> >> addition to what we already provide in order to account for things like
> >> slab more precisely.
> >
> > How do I even explain a slab? What about a slob or slub?
> > A few years from now, will this allocator even exist?
> >
> > Remember that I need something for the man page, and most
> > of my audience knows almost nothing about programming.
>
> It's not the difference between SLAB, SLOB and SLUB that matters here,
> but the fact that some of the memory allocated by these kernel
> allocators can be reclaimed. The procps tools currently count
> reclaimable SLAB / SLOB / SLUB memory as used memory, which is
> misleading. How can this be explained to someone who is not a
> programmer ?
I actually think it is probably OK to call them "cache". They *are*
quite similar to the page cache from a user's perspective. I just have
a problem with changing it *now*, though.
Page cache is fundamentally user data. It is verbatim in memory exactly
what came off or is going to the filesystem, and gets exposed to
userspace directly.
The various sl*bs are fundamentally kernel data. They're never seen by
users directly.
So, if I were to write a tool that told users of both slab and page
cache, I'd probably say "file cache" and "kernel cache" or something to
that effect. It's a bit over-simplified, but I think it gets the point
across sufficiently. Personally, I'd probably rather see 'buffers' get
collapsed in with 'cache' and get a new column for sl*b.
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2009-04-14 18:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 21:55 procps and new kernel fields Dave Hansen
2009-04-07 4:40 ` [feedback] " Albert Cahalan
2009-04-07 13:02 ` Bart Van Assche
2009-04-14 18:35 ` Dave Hansen [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=1239734124.32604.100.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=acahalan@cs.uml.edu \
--cc=bart.vanassche@gmail.com \
--cc=linux-mm@kvack.org \
--cc=procps-feedback@lists.sf.net \
/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.