On Thu 27-03-14 11:38:30, Vladimir Davydov wrote:
On 03/27/2014 01:58 AM, Michal Hocko wrote:
On Wed 26-03-14 19:28:05, Vladimir Davydov wrote:
We have only a few places where we actually want to charge kmem so
instead of intruding into the general page allocation path with
__GFP_KMEMCG
On Thu 27-03-14 11:34:10, Vladimir Davydov wrote:
Hi Michal,
On 03/27/2014 01:53 AM, Michal Hocko wrote:
On Wed 26-03-14 19:28:04, Vladimir Davydov wrote:
We don't track any random page allocation, so we shouldn't track kmalloc
that falls back to the page allocator.
Why did we do
the next step is going to be adding a per kmem
cache flag specifying if allocations from this cache should be charged
so that accounting will work only for those caches that are marked so
explicitly.
How do you select which caches to track?
--
Michal Hocko
SUSE Labs
, order);
+ memcg_uncharge_slab(s, order);
}
#define need_reserve_slab_rcu
\
--
1.7.10.4
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Glauber Costa glom...@gmail.com
---
kernel/fork.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index f4b09bc15f3a..8209780cf732 100644
On Tue 18-03-14 12:14:37, Vladimir Davydov wrote:
On 03/17/2014 08:07 PM, Michal Hocko wrote:
On Thu 13-03-14 19:06:39, Vladimir Davydov wrote:
When we get to memcg cache destruction, either from the root cache
destruction path or when turning memcg offline, there still might be
memcg
On Tue 18-03-14 12:19:00, Vladimir Davydov wrote:
On 03/17/2014 08:42 PM, Michal Hocko wrote:
On Thu 13-03-14 19:06:40, Vladimir Davydov wrote:
We schedule memcg cache shrink+destruction work (memcg_params::destroy)
from two places: when we turn memcg offline
(memcg_create_cache_work_func). So although
this can race with memcg offlining the memcg itself will be still alive.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Glauber Costa glom...@gmail.com
---
mm/memcontrol.c
-by: Vladimir Davydov vdavy...@parallels.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Glauber Costa glom...@gmail.com
[...]
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org
frustrating for you but there is a lot of things
on my agenda now (and last few weeks). Sorry about that.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
that David was quite concerned about some
high level decisions. I have to check, re-read whether there are still
there.
I am sorry that it takes so long but I am really busy with internal
things recently.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel
different memcgs might share the same cache
and so the pages for that cache, no? Actually it would depend on timing
because a new page would be chaged for the current allocator.
cachep-memcg_params-memcg == memcg would prevent from such a merge
previously AFAICS, or am I still confused?
--
Michal Hocko
On Thu 06-02-14 18:15:50, Vladimir Davydov wrote:
On 02/06/2014 06:07 PM, Michal Hocko wrote:
On Tue 04-02-14 19:27:19, Vladimir Davydov wrote:
[...]
What does this patch change? Actually, it introduces no functional
changes - it only remove the code trying to find an alias for a memcg
On Tue 04-02-14 23:19:24, Vladimir Davydov wrote:
On 02/04/2014 08:03 PM, Michal Hocko wrote:
On Mon 03-02-14 19:54:38, Vladimir Davydov wrote:
Memcg-awareness turned kmem_cache_create() into a dirty interweaving of
memcg-only and except-for-memcg calls. To clean this up, let's create
On Thu 06-02-14 21:12:51, Vladimir Davydov wrote:
On 02/06/2014 08:41 PM, Michal Hocko wrote:
[...]
+int kmem_cache_create_memcg(struct mem_cgroup *memcg, struct kmem_cache
*cachep)
{
- return kmem_cache_create_memcg(NULL, name, size, align, flags, ctor,
NULL);
+ struct
different.
let's fix this by
exporting the id of kmem-active memcg via cgroup fs file
memory.kmem.id.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Nacked-by: Michal Hocko mho...@suse.cz
---
mm/memcontrol.c | 12
1 file changed, 12 insertions(+)
diff --git a/mm
to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo
= kasprintf(GFP_KERNEL, %s:%d,
+ name, memcg_cache_id(memcg));
if (!s-name)
goto out_free_cache;
--
1.7.10.4
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https
++;
/*
--
1.7.10.4
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
On Tue 04-02-14 18:59:23, Vladimir Davydov wrote:
On 02/04/2014 06:52 PM, Michal Hocko wrote:
On Sun 02-02-14 20:33:48, Vladimir Davydov wrote:
Suppose we are creating memcg cache A that could be merged with cache B
of the same memcg. Since any memcg cache has the same parameters as its
On Tue 04-02-14 19:11:24, Vladimir Davydov wrote:
On 02/04/2014 06:45 PM, Michal Hocko wrote:
On Sun 02-02-14 20:33:47, Vladimir Davydov wrote:
The cgroup name is not informative at all in case the cgroup hierarchy
is not flat. Besides, we can always find the memcg a particular cache
(name, GFP_KERNEL);
+ if (memcg)
+ s-name = memcg_create_cache_name(memcg, parent_cache);
+ else
+ s-name = kstrdup(name, GFP_KERNEL);
if (!s-name)
goto out_free_cache;
--
1.7.10.4
--
Michal Hocko
SUSE Labs
review the patch. Also what does `s' stand for and can we use a more
descriptive name, please?
[...]
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
On Thu 19-12-13 10:31:43, Vladimir Davydov wrote:
On 12/18/2013 08:56 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Glauber Costa
On Thu 19-12-13 10:32:29, Vladimir Davydov wrote:
On 12/18/2013 09:06 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:53, Vladimir Davydov wrote:
Plus, rename memcg_register_cache() to memcg_init_cache_params(),
because it actually does not register the cache anywhere, but simply
initialize
On Thu 19-12-13 12:00:58, Glauber Costa wrote:
On Thu, Dec 19, 2013 at 11:07 AM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 12/18/2013 09:41 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:55, Vladimir Davydov wrote:
The memcg_params::memcg_caches array can be updated concurrently
On Thu 19-12-13 12:51:38, Vladimir Davydov wrote:
On 12/19/2013 12:44 PM, Michal Hocko wrote:
On Thu 19-12-13 10:31:43, Vladimir Davydov wrote:
On 12/18/2013 08:56 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
Signed-off-by: Vladimir Davydov vdavy
On Thu 19-12-13 13:01:28, Vladimir Davydov wrote:
On 12/19/2013 12:48 PM, Michal Hocko wrote:
On Thu 19-12-13 10:32:29, Vladimir Davydov wrote:
On 12/18/2013 09:06 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:53, Vladimir Davydov wrote:
Plus, rename memcg_register_cache
On Thu 19-12-13 13:16:01, Vladimir Davydov wrote:
On 12/19/2013 01:10 PM, Michal Hocko wrote:
On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
On 12/18/2013 09:14 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
First, in memcg_create_kmem_cache() we should issue
array is accessed lock-free.
This patch fixes this by making memcg_params RCU-protected.
yes, I was thinking about something like this when talking about RCU
usage.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Johannes Weiner han...@cmpxchg.org
Cc
On Thu 19-12-13 13:29:59, Vladimir Davydov wrote:
On 12/19/2013 01:21 PM, Michal Hocko wrote:
On Thu 19-12-13 13:16:01, Vladimir Davydov wrote:
On 12/19/2013 01:10 PM, Michal Hocko wrote:
On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
On 12/18/2013 09:14 PM, Michal Hocko wrote
On Thu 19-12-13 13:36:42, Vladimir Davydov wrote:
On 12/19/2013 01:28 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:57, Vladimir Davydov wrote:
[...]
diff --git a/mm/slab.h b/mm/slab.h
index 1d8b53f..53b81a9 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -164,10 +164,16 @@ static inline
returns -ERRNO or 0 on success.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
to write a good comment about it (although
I'm rather poor at writing comments :-( )
A nice diagram would do as well...
Thanks!
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Glauber Costa glom...@gmail.com
Cc: Christoph Lameter c...@linux.com
Cc: Pekka Enberg penb...@kernel.org
Cc
and the name but wouldn't
memcg_alloc_cache_params suit better?
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Glauber Costa glom...@gmail.com
Cc: Christoph Lameter c...@linux.com
Cc: Pekka Enberg penb
be specific why we should do it.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Glauber Costa glom...@gmail.com
Cc: Christoph Lameter c...@linux.com
Cc: Pekka Enberg penb...@kernel.org
Cc: Andrew Morton a...@linux
::memcg_caches from memcg_create_kmem_cache() to
kmem_cache_create_memcg() to be called under the slab_mutex.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Glauber Costa glom...@gmail.com
Cc: Christoph Lameter c
On Tue 17-12-13 11:48:20, Glauber Costa wrote:
On Mon, Dec 16, 2013 at 8:47 PM, Michal Hocko mho...@suse.cz wrote:
On Sat 14-12-13 12:15:33, Vladimir Davydov wrote:
The mem_cgroup structure contains nr_node_ids pointers to
mem_cgroup_per_node objects, not the objects themselves.
Ouch
: reduce the
size of struct memcg 244-fold)
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Glauber Costa glom...@openvz.org
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
is impossible on vmalloc'd areas.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Michal Hocko mho...@suse.cz
Cc: Glauber Costa glom...@openvz.org
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
yes
of cache_from_memcg_idx but I
guess we want to use RCU here.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
On Mon 09-12-13 22:44:51, Vladimir Davydov wrote:
On 12/09/2013 07:22 PM, Michal Hocko wrote:
On Wed 04-12-13 15:56:51, Vladimir Davydov wrote:
On 12/04/2013 02:08 PM, Glauber Costa wrote:
Could you do something clever with just one flag? Probably yes. But I
doubt it would
be that much
work. But it would require a deep audit that the
above is correct in all places. For example we do not bother to check
static key during offline/free paths. I guess it should be harmless as
is but who knows...
I would rather see more detailed description of the current state first.
--
Michal Hocko
the charge won't be committed.
Or am I missing something?
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm
On Mon 02-12-13 22:26:48, Glauber Costa wrote:
On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote:
[CCing Glauber - please do so in other posts for kmem related changes]
On Mon 02-12-13 17:08:13, Vladimir Davydov wrote:
The KMEM_ACCOUNTED_ACTIVATED was introduced by commit
would much rather see a comprehensive
documentation of the whole enabling workflow. E.g. why do we need
ACTIVATED at all? Nobody seem to care in the code...
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir
On Wed 27-11-13 19:46:02, Vladimir Davydov wrote:
This function is not used outside of memcontrol.c so make it static.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Cc: Johannes Weiner han...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir Singh bsinghar...@gmail.com
Cc
?
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
until it goes away.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
kamezawa.hir...@jp.fujitsu.com
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Tejun Heo t...@kernel.org
Acked-by: Michal Hocko mho...@suse.cz
---
mm/memcontrol.c | 116
+++-
1 file changed, 115 insertions(+), 1
Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Suleiman Souhlal sulei...@google.com
CC: Tejun Heo t...@kernel.org
I thought I have acked the patch already
Acked-by: Michal Hocko mho...@suse.cz
---
include/linux/gfp.h | 3
On Tue 16-10-12 14:16:51, Glauber Costa wrote:
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Frederic Weisbecker fweis...@redhat.com
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Michal Hocko mho...@suse.cz
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb
On Fri 12-10-12 11:36:38, Glauber Costa wrote:
On 10/11/2012 02:11 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:10, Glauber Costa wrote:
[...]
+ if (!memcg-kmem_accounted val != RESOURCE_MAX) {
Just a nit but wouldn't memcg_kmem_is_accounted(memcg) be better than
directly checking
On Fri 12-10-12 11:45:46, Glauber Costa wrote:
On 10/11/2012 04:42 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:12, Glauber Costa wrote:
[...]
+ /*
+ * Conditions under which we can wait for the oom_killer.
+ * __GFP_NORETRY should be masked by __mem_cgroup_try_charge
On Fri 12-10-12 11:47:17, Glauber Costa wrote:
On 10/11/2012 05:11 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:15, Glauber Costa wrote:
Because kmem charges can outlive the cgroup, we need to make sure that
we won't free the memcg structure while charges are still in flight
On Fri 12-10-12 11:53:23, Glauber Costa wrote:
On 10/11/2012 06:35 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:20, Glauber Costa wrote:
[...]
Kernel memory limits are not imposed for the root cgroup. Usage for the
root
-cgroup may or may not be accounted.
+cgroup may or may
On Fri 12-10-12 12:44:57, Glauber Costa wrote:
On 10/12/2012 12:39 PM, Michal Hocko wrote:
On Fri 12-10-12 11:45:46, Glauber Costa wrote:
On 10/11/2012 04:42 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:12, Glauber Costa wrote:
[...]
+/*
+ * Conditions under which we
)
+ res_counter_uncharge(memcg-kmem, size);
+
+ return ret;
+}
OK
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
to a very high number (like RESOURCE_MAX - 1page - that no one
will ever hit, or equal to the user memory)
[ v4: make kmem files part of the main array;
do not allow limit to be set for non-empty cgroups ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
On Thu 11-10-12 12:11:19, Michal Hocko wrote:
On Mon 08-10-12 14:06:10, Glauber Costa wrote:
[...]
+static void memcg_kmem_set_active(struct mem_cgroup *memcg)
+{
+ set_bit(KMEM_ACCOUNTED_ACTIVE, memcg-kmem_accounted);
+}
+
+static bool memcg_kmem_is_accounted(struct mem_cgroup
On Thu 11-10-12 14:42:12, Michal Hocko wrote:
[...]
/*
* Keep reference on memcg while the page is charged to prevent
* group from vanishing because allocation can outlive their
* tasks. The reference is dropped in __memcg_kmem_uncharge_page
*/
please
: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal sulei...@google.com
OK, I like the optimization. I have just one comment to the
memcg_kmem_dead naming but other than that
Acked
On Thu 11-10-12 12:11:19, Michal Hocko wrote:
On Mon 08-10-12 14:06:10, Glauber Costa wrote:
+ cgroup_lock();
+ mutex_lock(set_limit_mutex);
+ if (!memcg-kmem_accounted val != RESOURCE_MAX) {
Just a nit but wouldn't memcg_kmem_is_accounted(memcg) be better than
directly checking
that is accounted.
[ v4: adapted this patch to the changes in kmem_accounted ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho
...@parallels.com
Tested-by: Greg Thelen gthe...@google.com
CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Tejun Heo t...@kernel.org
OK, it seems it is much easier this way.
Acked-by: Michal Hocko mho...@suse.cz
---
mm
--
To unsubscribe from this list: send the line unsubscribe cgroups in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https
On Wed 10-10-12 13:03:39, Glauber Costa wrote:
On 10/09/2012 07:35 PM, Michal Hocko wrote:
On Tue 09-10-12 19:14:57, Glauber Costa wrote:
On 10/09/2012 07:08 PM, Michal Hocko wrote:
As I have already mentioned in my previous feedback this is cetainly not
atomic as you the lock protects
on will be checking this value.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal sulei...@google.com
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
Reviewed-by: Michal Hocko mho...@suse.cz
unconditional, also declare it in trace code ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Suleiman Souhlal sulei...@google.com
Acked-by: Johannes Weiner han...@cmpxchg.org
(flags);
+ return ret;
As I have already mentioned in my previous feedback this is cetainly not
atomic as you the lock protects only one group in the hierarchy. How is
the return value from this function supposed to be used?
--
Michal Hocko
SUSE Labs
On Tue 09-10-12 19:14:57, Glauber Costa wrote:
On 10/09/2012 07:08 PM, Michal Hocko wrote:
As I have already mentioned in my previous feedback this is cetainly not
atomic as you the lock protects only one group in the hierarchy. How is
the return value from this function supposed to be used
and it seems that we are slowly getting there.
Thanks.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
On Tue 02-10-12 13:15:43, Glauber Costa wrote:
On 10/01/2012 09:00 PM, Michal Hocko wrote:
On Tue 25-09-12 12:52:50, Glauber Costa wrote:
For the root memcg, there is no need to rely on the res_counters.
This is true only if there are no children groups but once there is at
least one we
for. There
is no usage in this patch (except for create_unique_id in slub).
I guess that by root caches you mean all default caches with
memcg==NULL, right?
[...]
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org
where global knob would complicate it
considerably (do we really want on/off/per_hierarchy global knob?).
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
On Sun 30-09-12 17:25:42, Tejun Heo wrote:
On Fri, Sep 28, 2012 at 03:34:19PM +0400, Glauber Costa wrote:
On 09/27/2012 05:44 PM, Michal Hocko wrote:
Anyway, I have just noticed that __mem_cgroup_try_charge does
VM_BUG_ON(css_is_removed(memcg-css)) on a given memcg so you should
keep
On Fri 28-09-12 15:34:19, Glauber Costa wrote:
On 09/27/2012 05:44 PM, Michal Hocko wrote:
the reference count aquired by mem_cgroup_get will still prevent the
memcg from going away, no?
Yes but you are outside of the rcu now and we usually do css_get before
we rcu_unlock
...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal sulei...@google.com
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
Documentation/cgroups/resource_counter.txt | 7 ---
include/linux/res_counter.h| 12
On Mon 01-10-12 14:09:09, Glauber Costa wrote:
On 10/01/2012 01:48 PM, Michal Hocko wrote:
On Fri 28-09-12 15:34:19, Glauber Costa wrote:
On 09/27/2012 05:44 PM, Michal Hocko wrote:
the reference count aquired by mem_cgroup_get will still prevent the
memcg from going away, no?
Yes
On Mon 01-10-12 15:51:20, Glauber Costa wrote:
On 10/01/2012 03:51 PM, Michal Hocko wrote:
On Mon 01-10-12 14:09:09, Glauber Costa wrote:
On 10/01/2012 01:48 PM, Michal Hocko wrote:
On Fri 28-09-12 15:34:19, Glauber Costa wrote:
On 09/27/2012 05:44 PM, Michal Hocko wrote:
the reference
the last charge finally goes away.
[ v3: merged all lifecycle related patches in one ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho
--
To unsubscribe from this list: send the line unsubscribe cgroups in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel
-by: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal sulei...@google.com
Looks good.
Reviewed-by: Michal Hocko mho...@suse.cz
On Mon 01-10-12 16:29:11, Glauber Costa wrote:
On 10/01/2012 04:15 PM, Michal Hocko wrote:
Based on the previous discussions I guess this one will get reworked,
right?
Yes, but most of it stayed. The hierarchy part is gone, but because we
will still have kmem pages floating around
...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal sulei...@google.com
Reviewed-by: Michal Hocko mho...@suse.cz
---
include/linux/thread_info.h | 2 ++
kernel/fork.c | 4 ++--
2 files
-off-by: Glauber Costa glom...@parallels.com
Tested-by: Greg Thelen gthe...@google.com
CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
---
mm/memcontrol.c | 66
a lot of discussion that one has to read
through, didn't you :P
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
not
let enable accounting for a group with tasks then we get both
flexibility and reasonable semantic. A global switch sounds too coars to
me and it really not necessary.
Would this work with you?
--
Michal Hocko
SUSE Labs
___
Devel mailing list
Devel
On Thu 27-09-12 16:20:55, Glauber Costa wrote:
On 09/27/2012 04:15 PM, Michal Hocko wrote:
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level of
use_hierarchy fiasco. I'm gonna NACK on this.
As I said: all use cases I
On Thu 27-09-12 16:40:03, Glauber Costa wrote:
On 09/27/2012 04:40 PM, Michal Hocko wrote:
On Thu 27-09-12 16:20:55, Glauber Costa wrote:
On 09/27/2012 04:15 PM, Michal Hocko wrote:
On Wed 26-09-12 16:33:34, Tejun Heo wrote:
[...]
So, this seems properly crazy to me at the similar level
On Thu 27-09-12 15:31:57, Glauber Costa wrote:
On 09/26/2012 07:51 PM, Michal Hocko wrote:
On Tue 18-09-12 18:04:03, Glauber Costa wrote:
[...]
+ *_memcg = NULL;
+ rcu_read_lock();
+ p = rcu_dereference(current-mm-owner);
+ memcg = mem_cgroup_from_task(p);
mem_cgroup_from_task
of
__free_accounted_pages() and free_accounted_pages().
[ v2: inverted test order to avoid a memcg_get leak,
free_accounted_pages simplification ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho
On Thu 27-09-12 07:33:00, Tejun Heo wrote:
Hello, Michal.
On Thu, Sep 27, 2012 at 02:08:06PM +0200, Michal Hocko wrote:
Yes, because we have many users (basically almost all) who care only
about the user memory because that's what occupies the vast majority of
the memory. They usually
this to happen once the cgroup has tasks
takes care of this, and is something I thought of myself.
You mean Michal's? It should also disallow switching if there are
children cgroups, right?
Right.
--
Michal Hocko
SUSE Labs
___
Devel mailing list
(like RESOURCE_MAX - 1page - that no one
will ever hit, or equal to the user memory)
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
Acked-by: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
mm/memcontrol.c | 64
and surroundings for more clarity ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Johannes Weiner han...@cmpxchg.org
---
include
On Wed 26-09-12 18:33:10, Glauber Costa wrote:
On 09/26/2012 06:03 PM, Michal Hocko wrote:
On Tue 18-09-12 18:04:01, Glauber Costa wrote:
[...]
@@ -4961,6 +5015,12 @@ mem_cgroup_create(struct cgroup *cont)
int cpu;
enable_swap_cgroup();
parent = NULL
On Fri 17-08-12 14:36:00, Glauber Costa wrote:
On 08/17/2012 02:35 PM, Michal Hocko wrote:
But I never said that can't happen. I said (ok, I meant) the static
branches can't be disabled.
Ok, then I misunderstood that because the comment was there even before
static branches were
limit as well.
Signed-off-by: Glauber Costa glom...@parallels.com
Acked-by: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal
1 - 100 of 154 matches
Mail list logo
