linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Thomas Garnier <thgarnie@google.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Thelen <gthelen@google.com>
Subject: Re: [PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB
Date: Wed, 26 Oct 2016 15:47:13 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1610261541560.3235@east.gentwo.org> (raw)
In-Reply-To: <CAJcbSZHZdiMpd4Nhr+UjBk5=5EmUb7xT-8VvCch2NHkm95415g@mail.gmail.com>

On Wed, 26 Oct 2016, Thomas Garnier wrote:

> Okay, I think for SLAB we can allow everything except the two flags
> mentioned here.

No no no. Just allow the flags already defined in include/linux/slab.h
that can be specd by subsystems when they call into the slab allocators.

> Should I deny certain flags for SLUB? I can allow everything for now.

All allocator should just allow flags defined in include/linux/slab.h be
passed to kmem_cache_create(). That is the API that all allocators need to support.
If someone wants to add new flags then we need to make sure that all
allocators can handle it.


The flags are (from include/linux/slab.h)
/*
 * Flags to pass to kmem_cache_create().
 */
#define SLAB_CONSISTENCY_CHECKS 0x00000100UL    /* DEBUG: Perform (expensive) checks on alloc/free */
#define SLAB_RED_ZONE           0x00000400UL    /* DEBUG: Red zone objs in a cache */
#define SLAB_POISON             0x00000800UL    /* DEBUG: Poison objects */
#define SLAB_HWCACHE_ALIGN      0x00002000UL    /* Align objs on cache lines */
#define SLAB_CACHE_DMA          0x00004000UL    /* Use GFP_DMA memory */
#define SLAB_STORE_USER         0x00010000UL    /* DEBUG: Store the last owner for bug hunting */
#define SLAB_PANIC              0x00040000UL    /* Panic if kmem_cache_create() fails */
#define SLAB_DESTROY_BY_RCU     0x00080000UL    /* Defer freeing slabs to RCU */
#define SLAB_MEM_SPREAD         0x00100000UL    /* Spread some memory over cpuset */
#define SLAB_TRACE              0x00200000UL    /* Trace allocations and frees */
#define SLAB_DEBUG_OBJECTS	0x00400000UL
#define SLAB_NOLEAKTRACE 	0x00800000UL    /* Avoid kmemleak tracing
#define SLAB_NOTRACK      	0x01000000UL
#define SLAB_FAILSLAB          	0x02000000UL    /* Fault injection mark */
#define SLAB_ACCOUNT          	0x04000000UL    /* Account to memcg */
#define SLAB_KASAN              0x08000000UL
#define SLAB_RECLAIM_ACCOUNT    0x00020000UL            /* Objects are reclaimable */

--
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>

  reply	other threads:[~2016-10-26 20:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 17:41 Thomas Garnier
2016-10-26 19:08 ` Christoph Lameter
2016-10-26 19:22   ` Thomas Garnier
2016-10-26 20:47     ` Christoph Lameter [this message]
2016-10-27  7:25 ` Michal Hocko
2016-10-27 14:34   ` Thomas Garnier

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.20.1610261541560.3235@east.gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=gthelen@google.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=thgarnie@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