From: Tejun Heo <tj@kernel.org>
To: Glauber Costa <glommer@parallels.com>
Cc: Christoph Lameter <cl@linux.com>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com,
Li Zefan <lizefan@huawei.com>, Greg Thelen <gthelen@google.com>,
Suleiman Souhlal <suleiman@google.com>,
Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
devel@openvz.org, David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH v3 13/28] slub: create duplicate cache
Date: Wed, 30 May 2012 10:29:55 +0900 [thread overview]
Message-ID: <20120530012955.GA4854@google.com> (raw)
In-Reply-To: <4FC530C0.30509@parallels.com>
Hello, Christoph, Glauber.
On Wed, May 30, 2012 at 12:25:36AM +0400, Glauber Costa wrote:
> >We have never worked container like logic like that in the kernel due to
> >the complicated logic you would have to put in. The requirement that all
> >objects in a page come from the same container is not necessary. If you
> >drop this notion then things become very easy and the patches will become
> >simple.
>
> I promise to look at that in more detail and get back to it. In the
> meantime, I think it would be enlightening to hear from other
> parties as well, specially the ones also directly interested in
> using the technology.
I don't think I'm too interested in using the technology ;) and
haven't read the code (just glanced through the descriptions and
discussions), but, in general, I think the approach of duplicating
memory allocator per-memcg is a sane approach. It isn't the most
efficient one with the possibility of wasting considerable amount of
caching area per memcg but it is something which can mostly stay out
of the way if done right and that's how I want cgroup implementations
to be.
The two goals for cgroup controllers that I think are important are
proper (no, not crazy perfect but good enough) isolation and an
implementation which doesn't impact !cg path in an intrusive manner -
if someone who doesn't care about cgroup but knows and wants to work
on the subsystem should be able to mostly ignore cgroup support. If
that means overhead for cgroup users, so be it.
Without looking at the actual code, my rainbow-farting unicorn here
would be having a common slXb interface layer which handles
interfacing with memory allocator users and cgroup and let slXb
implement the same backend interface which doesn't care / know about
cgroup at all (other than using the correct allocation context, that
is). Glauber, would something like that be possible?
Thanks.
--
tejun
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-30 1:30 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 13:03 [PATCH v3 00/28] kmem limitation for memcg Glauber Costa
2012-05-25 13:03 ` [PATCH v3 01/28] slab: move FULL state transition to an initcall Glauber Costa
2012-05-25 13:03 ` [PATCH v3 02/28] memcg: Always free struct memcg through schedule_work() Glauber Costa
2012-05-25 13:03 ` [PATCH v3 03/28] slab: rename gfpflags to allocflags Glauber Costa
2012-05-25 13:03 ` [PATCH v3 04/28] memcg: Make it possible to use the stock for more than one page Glauber Costa
2012-05-25 13:03 ` [PATCH v3 05/28] memcg: Reclaim when more than one page needed Glauber Costa
2012-05-29 14:19 ` Christoph Lameter
2012-05-29 14:20 ` Christoph Lameter
2012-05-29 15:45 ` Glauber Costa
2012-05-25 13:03 ` [PATCH v3 06/28] slab: use obj_size field of struct kmem_cache when not debugging Glauber Costa
2012-05-25 13:03 ` [PATCH v3 07/28] memcg: change defines to an enum Glauber Costa
2012-05-25 13:03 ` [PATCH v3 08/28] res_counter: don't force return value checking in res_counter_charge_nofail Glauber Costa
2012-05-25 13:03 ` [PATCH v3 09/28] kmem slab accounting basic infrastructure Glauber Costa
2012-05-25 13:03 ` [PATCH v3 10/28] slab/slub: struct memcg_params Glauber Costa
2012-05-25 13:03 ` [PATCH v3 11/28] slub: consider a memcg parameter in kmem_create_cache Glauber Costa
2012-05-25 13:03 ` [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create Glauber Costa
2012-05-29 14:27 ` Christoph Lameter
2012-05-29 15:50 ` Glauber Costa
2012-05-29 16:33 ` Christoph Lameter
2012-05-29 16:36 ` Glauber Costa
2012-05-29 16:52 ` Christoph Lameter
2012-05-29 16:59 ` Glauber Costa
2012-05-30 11:01 ` Frederic Weisbecker
2012-05-25 13:03 ` [PATCH v3 13/28] slub: create duplicate cache Glauber Costa
2012-05-29 14:36 ` Christoph Lameter
2012-05-29 15:56 ` Glauber Costa
2012-05-29 16:05 ` Christoph Lameter
2012-05-29 17:05 ` Glauber Costa
2012-05-29 17:25 ` Christoph Lameter
2012-05-29 17:27 ` Glauber Costa
2012-05-29 19:26 ` Christoph Lameter
2012-05-29 19:40 ` Glauber Costa
2012-05-29 19:55 ` Christoph Lameter
2012-05-29 20:08 ` Glauber Costa
2012-05-29 20:21 ` Christoph Lameter
2012-05-29 20:25 ` Glauber Costa
2012-05-30 1:29 ` Tejun Heo [this message]
2012-05-30 7:28 ` [Devel] " James Bottomley
2012-05-30 7:54 ` Glauber Costa
2012-05-30 8:02 ` Tejun Heo
2012-05-30 15:37 ` Christoph Lameter
2012-05-29 20:57 ` Suleiman Souhlal
2012-05-25 13:03 ` [PATCH v3 14/28] slab: " Glauber Costa
2012-05-25 13:03 ` [PATCH v3 15/28] slub: always get the cache from its page in kfree Glauber Costa
2012-05-29 14:42 ` Christoph Lameter
2012-05-29 15:59 ` Glauber Costa
2012-05-25 13:03 ` [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure Glauber Costa
2012-05-29 14:47 ` Christoph Lameter
2012-05-29 16:00 ` Glauber Costa
2012-05-30 12:17 ` Frederic Weisbecker
2012-05-30 12:26 ` Glauber Costa
2012-05-30 12:34 ` Frederic Weisbecker
2012-05-30 12:38 ` Glauber Costa
2012-05-30 13:11 ` Frederic Weisbecker
2012-05-30 13:09 ` Glauber Costa
2012-05-30 13:04 ` Frederic Weisbecker
2012-05-30 13:06 ` Glauber Costa
2012-05-30 13:37 ` Frederic Weisbecker
2012-05-30 13:37 ` Glauber Costa
2012-05-30 13:53 ` Frederic Weisbecker
2012-05-30 13:55 ` Glauber Costa
2012-05-30 15:33 ` Frederic Weisbecker
2012-05-30 16:16 ` Glauber Costa
2012-05-25 13:03 ` [PATCH v3 17/28] skip memcg kmem allocations in specified code regions Glauber Costa
2012-05-25 13:03 ` [PATCH v3 18/28] slub: charge allocation to a memcg Glauber Costa
2012-05-29 14:51 ` Christoph Lameter
2012-05-29 16:06 ` Glauber Costa
2012-05-25 13:03 ` [PATCH v3 19/28] slab: per-memcg accounting of slab caches Glauber Costa
2012-05-29 14:52 ` Christoph Lameter
2012-05-29 16:07 ` Glauber Costa
2012-05-29 16:13 ` Glauber Costa
2012-05-25 13:03 ` [PATCH v3 20/28] memcg: disable kmem code when not in use Glauber Costa
2012-05-25 13:03 ` [PATCH v3 21/28] memcg: destroy memcg caches Glauber Costa
2012-05-25 13:03 ` [PATCH v3 22/28] memcg/slub: shrink dead caches Glauber Costa
2012-05-25 13:03 ` [PATCH v3 23/28] slab: Track all the memcg children of a kmem_cache Glauber Costa
2012-05-25 13:03 ` [PATCH v3 24/28] memcg: Per-memcg memory.kmem.slabinfo file Glauber Costa
2012-05-25 13:03 ` [PATCH v3 25/28] slub: create slabinfo file for memcg Glauber Costa
2012-05-25 13:03 ` [PATCH v3 26/28] slub: track all children of a kmem cache Glauber Costa
2012-05-25 13:03 ` [PATCH v3 27/28] memcg: propagate kmem limiting information to children Glauber Costa
2012-05-25 13:03 ` [PATCH v3 28/28] Documentation: add documentation for slab tracker for memcg Glauber Costa
2012-05-25 13:34 ` [PATCH v3 00/28] kmem limitation " Michal Hocko
2012-05-25 14:34 ` Christoph Lameter
2012-05-28 8:32 ` Glauber Costa
2012-05-29 15:07 ` Christoph Lameter
2012-05-29 15:44 ` Glauber Costa
2012-05-29 16:01 ` Christoph Lameter
2012-06-07 10:26 ` Frederic Weisbecker
2012-06-07 10:53 ` Glauber Costa
2012-06-07 14:00 ` Frederic Weisbecker
2012-06-14 2:24 ` Kamezawa Hiroyuki
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=20120530012955.GA4854@google.com \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=devel@openvz.org \
--cc=glommer@parallels.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@suse.cz \
--cc=penberg@cs.helsinki.fi \
--cc=rientjes@google.com \
--cc=suleiman@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;
as well as URLs for NNTP newsgroup(s).