From: Christoph Lameter <cl@linux.com>
To: WANG Chao <chaowang@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"open list:SLAB ALLOCATOR" <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm, slub: do not add duplicate sysfs
Date: Thu, 28 Aug 2014 09:47:47 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.11.1408280947270.3275@gentwo.org> (raw)
In-Reply-To: <20140828043211.GD3971@dhcp-17-37.nay.redhat.com>
On Thu, 28 Aug 2014, WANG Chao wrote:
> What about failslab_store()? SLAB_FAILSLAB is also a nomerge flag.
Subject: slub: Disable tracing and failslab for merged slabs
Tracing of mergeable slabs as well as uses of failslab are
confusing since the objects of multiple slab caches will be
affected. Moreover this creates a situation where a mergeable
slab will become unmergeable.
If tracing or failslab testing is desired then it may be best to
switch merging off for starters.
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/mm/slub.c
===================================================================
--- linux.orig/mm/slub.c 2014-08-08 11:52:30.039681592 -0500
+++ linux/mm/slub.c 2014-08-28 09:45:58.748840392 -0500
@@ -4604,6 +4604,14 @@ static ssize_t trace_show(struct kmem_ca
static ssize_t trace_store(struct kmem_cache *s, const char *buf,
size_t length)
{
+ /*
+ * Tracing a merged cache is going to give confusing results
+ * as well as cause other issues like converting a mergeable
+ * cache into an umergeable one.
+ */
+ if (s->refcount > 1)
+ return -EINVAL;
+
s->flags &= ~SLAB_TRACE;
if (buf[0] == '1') {
s->flags &= ~__CMPXCHG_DOUBLE;
@@ -4721,6 +4729,9 @@ static ssize_t failslab_show(struct kmem
static ssize_t failslab_store(struct kmem_cache *s, const char *buf,
size_t length)
{
+ if (s->refcount > 1)
+ return -EINVAL;
+
s->flags &= ~SLAB_FAILSLAB;
if (buf[0] == '1')
s->flags |= SLAB_FAILSLAB;
--
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>
next prev parent reply other threads:[~2014-08-28 14:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 15:14 WANG Chao
2014-08-27 15:25 ` Christoph Lameter
2014-08-27 15:32 ` Christoph Lameter
2014-08-28 4:32 ` WANG Chao
2014-08-28 14:47 ` Christoph Lameter [this message]
2014-08-29 5:09 ` WANG Chao
2014-08-28 3:42 ` WANG Chao
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=alpine.DEB.2.11.1408280947270.3275@gentwo.org \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=chaowang@redhat.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 \
/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