From: Michal Hocko <mhocko@kernel.org>
To: Knut Omang <knut.omang@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: provide interface for retrieving kmem_cache name
Date: Thu, 7 Nov 2019 14:13:42 +0100 [thread overview]
Message-ID: <20191107131342.GT8314@dhcp22.suse.cz> (raw)
In-Reply-To: <27006f47b0b85fb99acee2a638207268aef8d010.camel@oracle.com>
On Thu 07-11-19 13:26:09, Knut Omang wrote:
> On Thu, 2019-11-07 at 12:58 +0100, Michal Hocko wrote:
> > On Thu 07-11-19 12:54:04, Knut Omang wrote:
> > > With the restructuring done in commit 9adeaa226988
> > > ("mm, slab: move memcg_cache_params structure to mm/slab.h")
> > >
> > > it is no longer possible for code external to mm to access
> > > the name of a kmem_cache as struct kmem_cache has effectively become
> > > opaque. Having access to the cache name is helpful to kernel testing
> > > infrastructure.
> > >
> > > Expose a new function kmem_cache_name to mitigate that.
> >
> > Who is going to use that symbol? It is preferred that a user is added in
> > the same patch as the newly added symbol.
>
> Yes, I am aware that that's the normal practice,
> we're currently using cache->name directly in the kernel
> unit test framework KTF (https://github.com/oracle/ktf/)
> which we are working (https://lkml.org/lkml/2019/8/13/111) to get
> into the kernel in one form or another.
Please add the export with a patch that really needs it.
> To me this seems like a natural part of an API for the kmem_cache
> data structure now that it has in effect become opaque, so it seemed
> appropriate to get it in close in time to the patch that no longer
> makes this possible, instead of someone else hitting this down the road.
Well, this is something for SLAB maintainers but I do not really think
the name is something the in kernel code should care about. It is solely
for presenting reasonable statistics to the userspace and that code
workds just fine AFAIK.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-11-07 13:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 11:54 Knut Omang
2019-11-07 11:58 ` Michal Hocko
2019-11-07 12:26 ` Knut Omang
2019-11-07 13:13 ` Michal Hocko [this message]
2019-11-07 20:50 ` David Rientjes
2019-11-08 15:37 ` Christopher Lameter
2019-11-08 16:44 ` Knut Omang
2019-11-08 16:49 ` Christopher Lameter
2019-11-08 20:40 ` Knut Omang
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=20191107131342.GT8314@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=knut.omang@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/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