From: Glauber Costa <glommer@parallels.com>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@suse.cz>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH] slab: Ignore internal flags in cache creation
Date: Wed, 26 Sep 2012 12:43:21 +0400 [thread overview]
Message-ID: <5062C029.308@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1209251744580.22521@chino.kir.corp.google.com>
On 09/26/2012 04:46 AM, David Rientjes wrote:
> On Tue, 25 Sep 2012, Christoph Lameter wrote:
>
>>> No cache should ever pass those as a creation flags. We can just ignore
>>> this bit if it happens to be passed (such as when duplicating a cache in
>>> the kmem memcg patches)
>>
>> Acked-by: Christoph Lameter <cl@linux.com>
>>
>
> Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
> the flag extensions beyond those defined in the generic slab.h header are
> implementation defined. It may be true that SLAB uses a bit only
> internally (and already protects it with a BUG_ON() in
> __kmem_cache_create()) but that doesn't mean other implementations can't
> use such a flag that would be a no-op on another allocator.
>
So the problem I am facing here is that when I am creating caches from
memcg, I would very much like to reuse their flags fields. They are
stored in the cache itself, so this is not a problem. But slab also
stores that flag, leading to the precise BUG_ON() on CREATE_MASK that
you quoted.
In this context, passing this flag becomes completely valid, I just need
that to be explicitly masked out.
What is your suggestion to handle this ?
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Michal Hocko <mhocko@suse.cz>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH] slab: Ignore internal flags in cache creation
Date: Wed, 26 Sep 2012 12:43:21 +0400 [thread overview]
Message-ID: <5062C029.308@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1209251744580.22521@chino.kir.corp.google.com>
On 09/26/2012 04:46 AM, David Rientjes wrote:
> On Tue, 25 Sep 2012, Christoph Lameter wrote:
>
>>> No cache should ever pass those as a creation flags. We can just ignore
>>> this bit if it happens to be passed (such as when duplicating a cache in
>>> the kmem memcg patches)
>>
>> Acked-by: Christoph Lameter <cl@linux.com>
>>
>
> Nack, this is already handled by CREATE_MASK in the mm/slab.c allocator;
> the flag extensions beyond those defined in the generic slab.h header are
> implementation defined. It may be true that SLAB uses a bit only
> internally (and already protects it with a BUG_ON() in
> __kmem_cache_create()) but that doesn't mean other implementations can't
> use such a flag that would be a no-op on another allocator.
>
So the problem I am facing here is that when I am creating caches from
memcg, I would very much like to reuse their flags fields. They are
stored in the cache itself, so this is not a problem. But slab also
stores that flag, leading to the precise BUG_ON() on CREATE_MASK that
you quoted.
In this context, passing this flag becomes completely valid, I just need
that to be explicitly masked out.
What is your suggestion to handle this ?
next prev parent reply other threads:[~2012-09-26 8:46 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 11:17 [PATCH] slab: Ignore internal flags in cache creation Glauber Costa
2012-09-25 11:17 ` Glauber Costa
2012-09-25 16:26 ` Christoph Lameter
2012-09-25 16:26 ` Christoph Lameter
2012-09-26 0:46 ` David Rientjes
2012-09-26 0:46 ` David Rientjes
2012-09-26 8:43 ` Glauber Costa [this message]
2012-09-26 8:43 ` Glauber Costa
2012-09-27 1:16 ` David Rientjes
2012-09-27 1:16 ` David Rientjes
2012-09-27 6:59 ` Glauber Costa
2012-09-27 6:59 ` Glauber Costa
2012-09-27 22:56 ` David Rientjes
2012-09-27 22:56 ` David Rientjes
2012-09-28 7:46 ` Glauber Costa
2012-09-28 7:46 ` Glauber Costa
2012-09-28 20:25 ` David Rientjes
2012-09-28 20:25 ` David Rientjes
2012-09-28 14:12 ` Christoph Lameter
2012-09-28 14:12 ` Christoph Lameter
2012-09-28 20:39 ` David Rientjes
2012-09-28 20:39 ` David Rientjes
2012-09-28 21:20 ` Christoph Lameter
2012-09-28 21:20 ` Christoph Lameter
2012-09-28 23:11 ` David Rientjes
2012-09-28 23:11 ` David Rientjes
2012-10-01 17:54 ` Christoph Lameter
2012-10-01 17:54 ` Christoph Lameter
2012-10-01 7:28 ` Pekka Enberg
2012-10-01 7:28 ` Pekka Enberg
2012-10-01 7:58 ` Glauber Costa
2012-10-01 7:58 ` Glauber Costa
2012-09-27 13:54 ` Christoph Lameter
2012-09-27 13:54 ` Christoph Lameter
2012-09-27 22:50 ` David Rientjes
2012-09-27 22:50 ` David Rientjes
2012-09-28 14:04 ` Christoph Lameter
2012-09-28 14:04 ` Christoph Lameter
2012-09-28 20:36 ` David Rientjes
2012-09-28 20:36 ` David Rientjes
2012-09-26 14:57 ` Christoph Lameter
2012-09-26 14:57 ` Christoph Lameter
2012-09-27 1:12 ` David Rientjes
2012-09-27 1:12 ` David Rientjes
2012-09-27 13:57 ` Christoph Lameter
2012-09-27 13:57 ` Christoph Lameter
2012-09-27 22:52 ` David Rientjes
2012-09-27 22:52 ` David Rientjes
2012-09-28 14:10 ` Christoph Lameter
2012-09-28 14:10 ` Christoph Lameter
2012-09-28 20:30 ` David Rientjes
2012-09-28 20:30 ` David Rientjes
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=5062C029.308@parallels.com \
--to=glommer@parallels.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=penberg@cs.helsinki.fi \
--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 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.