From: "Tobin C. Harding" <me@tobin.cc>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
"Tobin C. Harding" <tobin@kernel.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slab: Increase width of first /proc/slabinfo column
Date: Mon, 4 Feb 2019 16:55:26 +1100 [thread overview]
Message-ID: <20190204055526.GA14242@eros.localdomain> (raw)
In-Reply-To: <20190201140346.fdcd6c4b663fbe3b5d93820d@linux-foundation.org>
On Fri, Feb 01, 2019 at 02:03:46PM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2019 18:43:10 -0800 Matthew Wilcox <willy@infradead.org> wrote:
>
> > On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote:
> > > Currently when displaying /proc/slabinfo if any cache names are too long
> > > then the output columns are not aligned. We could do something fancy to
> > > get the maximum length of any cache name in the system or we could just
> > > increase the hardcoded width. Currently it is 17 characters. Monitors
> > > are wide these days so lets just increase it to 30 characters.
> >
> > I had a proposal some time ago to turn the slab name from being kmalloced
> > to being an inline 16 bytes (with some fun hacks for cgroups). I think
> > that's a better approach than permitting such long names. For example,
> > ext4_allocation_context could be shortened to ext4_alloc_ctx without
> > losing any expressivity.
> >
>
> There are some back-compatibility concerns here.
I'm don't understand sorry what back-compatibility concerns (please see
sentiment at end of email :)
> And truncating long names might result in duplicates.
So I thought I had a good idea - add a pr_warn() if cache name > 16 and
patch all current intree calls to kmem_cache_create() called as such.
This process very kindly lead me to the fact that this does *not* work
because of the macro KMEM_CACHE (which uses the struct name as the cache
name).
So, back to the drawing board. I'm concerned that this may be a waste
of peoples time, if so please say so and I'll move on to something else.
thanks,
Tobin.
next prev parent reply other threads:[~2019-02-04 5:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 0:42 [PATCH] mm/slab: Increase width of first /proc/slabinfo column Tobin C. Harding
2019-02-01 0:58 ` Tobin C. Harding
2019-02-01 1:13 ` Andrew Morton
2019-02-01 2:56 ` Tobin C. Harding
2019-02-01 2:34 ` Christopher Lameter
2019-02-02 6:47 ` Pekka Enberg
2019-02-01 2:43 ` Matthew Wilcox
2019-02-01 2:58 ` Tobin C. Harding
2019-02-01 22:03 ` Andrew Morton
2019-02-04 5:55 ` Tobin C. Harding [this message]
2019-02-04 1:35 ` Tobin C. Harding
2019-02-02 3:27 ` Joe Perches
2019-02-03 23:34 ` Tobin C. Harding
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=20190204055526.GA14242@eros.localdomain \
--to=me@tobin.cc \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tobin@kernel.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).