it for this
moment) I get to bad_page path and need to reboot...
What am I missing? Am I using migrate_pages correctly?
Thanks for any suggestions.
(please add me to cc: because I am not list member)
P.S.
I am using vanilla 2.6.18 source tree.
Best regards
--
Michal Hocko
-
To unsubscribe from
uses put_lru=0. See the attached
patch.
What do you think about that. Is this way correct?
(Please add me to CC, because I am not list member)
Best regards
--
Michal Hocko
--- /usr/src/linux-vanilla/mm/migrate.c 2006-12-02 15:08:23.0 +0100
+++ /usr/src/linux/mm/migrate.c 2007-03-12 18:44
On Mon 29-10-12 13:40:39, David Rientjes wrote:
On Mon, 29 Oct 2012, Michal Hocko wrote:
N_HIGH_MEMORY stands for the nodes that has normal or high memory.
N_MEMORY stands for the nodes that has any memory.
What is the difference of those two?
Patch 5 in the series
Strange, I
On Mon 29-10-12 14:08:05, David Rientjes wrote:
On Mon, 29 Oct 2012, Michal Hocko wrote:
N_HIGH_MEMORY stands for the nodes that has normal or high memory.
N_MEMORY stands for the nodes that has any memory.
What is the difference of those two?
Patch 5
?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
Could you take care of them and apply those two on top of the first one
which guarantees that css_tryget fails and no new task can appear in the
group (aka #4 without follow up cleanups)? So that Andrew doesn't have
to care about them later.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe
init_section_page_cgroup(pfn, nid) later which allocates
page_cgroup descriptors which are not movable. Or is there any code in
your patchset that handles this?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
is really encouraging
Reviewed-by: Michal Hocko mho...@suse.cz
with a minor note bellow
---
include/linux/cgroup.h | 12
kernel/cgroup.c| 159
-
2 files changed, 38 insertions(+), 133 deletions(-)
[...]
diff --git a/kernel/cgroup.c b
...@cmpxchg.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Few questions/suggestions below but it looks good in general to me.
Reviewed-by: Michal Hocko mho...@suse.cz
---
include/linux/cgroup.h | 6 --
kernel
such that locking is contained inside cgroup proper and
we don't get nasty surprises if we ever grow another caller of
cgroup_create().
Signed-off-by: Tejun Heo t...@kernel.org
Looks good. Just a nit bellow
Reviewed-by: Michal Hocko mho...@suse.cz
---
kernel/cgroup.c | 16 +---
1 file
destroyed.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Michal Hocko mho...@suse.cz
---
kernel/cgroup.c | 41 +++--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index b3010ae..66204a6 100644
it and all the mechanisms supporting it. Note
that memcontrol.c changes are essentially revert of 887032670d
(cgroup avoid permanent sleep at rmdir).
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir
On Tue 30-10-12 21:22:45, Tejun Heo wrote:
All -pre_destory() implementations return 0 now, which is the only
allowed return value. Make it return void.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki
/hugetlb_cgroup.c| 11 +--
mm/memcontrol.c| 51 ++
5 files changed, 75 insertions(+), 287 deletions(-)
speaks for itself.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wed 31-10-12 09:41:23, Tejun Heo wrote:
Hey, Michal.
On Wed, Oct 31, 2012 at 03:37:51PM +0100, Michal Hocko wrote:
+ for_each_subsys(cgrp-root, ss)
+ if (ss-pre_destroy)
+ WARN_ON_ONCE(ss-pre_destroy(cgrp));
Hmm, I am not sure I like this WARN_ON_ONCE
;
}
mutex_lock(cgroup_mutex);
parent = cgrp-parent;
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed 31-10-12 09:57:39, Tejun Heo wrote:
Hey, Michal.
On Wed, Oct 31, 2012 at 04:39:26PM +0100, Michal Hocko wrote:
prepare_to_wait(cgroup_rmdir_waitq, wait, TASK_INTERRUPTIBLE);
- local_irq_disable();
-
OK, so the new charges shouldn't come from the IRQ context so we
IRQ context
(does this really happen btw.?) which would interrupt cgroup_rmdir
between we add CSS_DEACT_BIAS and the group is marked CGRP_REMOVED.
Or am I still missing the point?
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
mentioned one can trigger it really easily.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Wed 31-10-12 13:11:02, Tejun Heo wrote:
Hello,
On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko mho...@suse.cz wrote:
local_irq_disable doesn't guarantee atomicity, because other CPUs will
Maybe it should say atomicity on the local CPU.
That would be more clear but being more verbose
that css_tryget() isn't called from
IRQ context on the same CPU while lower context is between CSS
deactivation and setting CSS_REMOVED as css_tryget() would hang
forever in such cases waiting for CSS to be re-activated or
CSS_REMOVED set. This will go away soon.
Much better. Thanks a lot!
--
Michal
On Wed 31-10-12 13:14:07, Tejun Heo wrote:
Hey, Michal.
On Wed, Oct 31, 2012 at 1:12 PM, Michal Hocko mho...@suse.cz wrote:
And sorry for being to annoying about this WARN_ON_ONCE but I really
don't see any reason for it. pre_destroy can still happen and now it is
even reduced
On Wed 31-10-12 12:44:10, Tejun Heo wrote:
All -pre_destory() implementations return 0 now, which is the only
allowed return value. Make it return void.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Michal Hocko mho...@suse.cz
Cc: Balbir Singh bsinghar...@gmail.com
Cc: KAMEZAWA Hiroyuki
.
+ */
+ mutex_unlock(cgroup_mutex);
+ for_each_subsys(cgrp-root, ss)
+ if (ss-pre_destroy)
+ WARN_ON_ONCE(ss-pre_destroy(cgrp));
Do you think that BUG_ON would be too harsh?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed 31-10-12 14:27:25, Tejun Heo wrote:
Hey, Michal.
On Wed, Oct 31, 2012 at 10:23:59PM +0100, Michal Hocko wrote:
+ for_each_subsys(cgrp-root, ss)
+ if (ss-pre_destroy)
+ WARN_ON_ONCE(ss-pre_destroy(cgrp));
Do you think that BUG_ON would be too harsh
On Wed 31-10-12 10:04:31, Tejun Heo wrote:
Hey, Michal.
On Wed, Oct 31, 2012 at 04:55:14PM +0100, Michal Hocko wrote:
+ /*
+ * Only live parents can have children. Note that the liveliness
+ * check isn't strictly necessary because cgroup_mkdir() and
+ * cgroup_rmdir
On Thu 01-11-12 07:52:24, Tejun Heo wrote:
Hey, Michal.
On Thu, Nov 1, 2012 at 2:16 AM, Michal Hocko mho...@suse.cz wrote:
I am not sure I understand. What does deactivate_super has to do with
the above suggestion? cgroup_lock_live_group will take the cgroup_mutex
on the success or frees
On Thu 01-11-12 16:05:32, Michal Hocko wrote:
On Thu 01-11-12 07:52:24, Tejun Heo wrote:
Hey, Michal.
On Thu, Nov 1, 2012 at 2:16 AM, Michal Hocko mho...@suse.cz wrote:
I am not sure I understand. What does deactivate_super has to do with
the above suggestion? cgroup_lock_live_group
accesscmpje so it shouldn't be noticable
(lruvec-zone is used most of the time later so it not a pointless
load).
It is also easier to backport for stable. But is there any reason to fix
it later properly in the hotadd hook?
Anyway
Acked-by: Michal Hocko mho...@suse.cz
Thanks!
---
I've marked
On Fri 02-11-12 11:21:59, Michal Hocko wrote:
On Thu 01-11-12 18:28:02, Hugh Dickins wrote:
[...]
And I forgot to mention that the following hunk will clash with
memcg: Simplify mem_cgroup_force_empty_list error handling which is in
linux-next already (via Tejun's tree).
Would it be easier
kmem and remaining umem to match. So *in theory* it should
be fine.
Where can I grab your final tree so I can test it and make sure it is
all good ?
Everything is in the -mm git tree (I tend to take mmots trees if they
compile).
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send
(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
a lot of discussion that one has to read
through, didn't you :P
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
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
--
To unsubscribe from this list: send the line unsubscribe linux
)
rcu_read_lock();
memcg = mem_cgroup_from_task(rcu_dereference((mm)-owner));
- match = __mem_cgroup_same_or_subtree(cgroup, memcg);
+ match = memcg __mem_cgroup_same_or_subtree(cgroup, memcg);
rcu_read_unlock();
return match;
}
--
1.7.11.4
--
Michal Hocko
SUSE Labs
On Thu 04-10-12 16:19:08, Johannes Weiner wrote:
On Thu, Oct 04, 2012 at 08:49:58PM +0200, Michal Hocko wrote:
On Thu 04-10-12 14:09:16, Johannes Weiner wrote:
page_referenced() counts only references of mm's that are associated
with the memcg hierarchy that is being reclaimed. However
;a=summary
since-3.6 branch. It is based on top of 3.6 with mm patches from
Andrew's tree.
HTH
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
and it seems that we are slowly getting there.
Thanks.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Fri 02-11-12 16:37:37, Hugh Dickins wrote:
On Fri, 2 Nov 2012, Michal Hocko wrote:
On Fri 02-11-12 11:21:59, Michal Hocko wrote:
On Thu 01-11-12 18:28:02, Hugh Dickins wrote:
[...]
And I forgot to mention that the following hunk will clash with
memcg: Simplify
On Mon 05-11-12 09:30:24, Tejun Heo wrote:
Applied to cgroup/cgroup-rmdir-updates and then pulled into
cgroup/for-3.8 w/ Li's acks added.
OK, I have merged it into -mm git tree.
Thanks
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
and if it decides then __always_inline will not help, right?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
;
a...@canonical.com; de...@linuxdriverproject.org; linux...@kvack.org;
Hiroyuki Kamezawa; Michal Hocko; Johannes Weiner; Ying Han
Subject: Re: [PATCH 1/2] mm: Export vm_committed_as
On Sat, 3 Nov 2012 14:09:38 +
KY Srinivasan k...@microsoft.com wrote:
Ok, but you're going
.
*/
usage = res_counter_read_u64(memcg-res, RES_USAGE) -
res_counter_read_u64(memcg-kmem, RES_USAGE);
} while (usage 0);
return 0;
}
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
is a
mystery.)
Strange indeed. The last commit changed it from long to s64 to suport
values bigger than 2^31 but even the original long doesn't make much
sense to me.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
CGROUP_FREEZING,
+ CGROUP_FREEZING_PARENT);
+ spin_unlock_irq(pos_f-lock);
+ }
+ rcu_read_unlock();
}
static int freezer_write(struct cgroup *cgroup, struct cftype *cft,
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send
because the shared state is now really easy
to implement.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Glauber Costa glom...@parallels.com
Acked-by: Michal Hocko mho...@suse.cz
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 12 ++--
2 files changed, 11 insertions(+), 2
of head. This isn't strictly necessary but is
done so that the iteration order is more conventional.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Michal Hocko mho...@suse.cz
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 8 +++-
2 files changed, 4 insertions(+), 5
.
Michal, Li, how does this look to you? Would this be okay for memcg
too?
Yes, definitely. We are currently iterating by css-id which is, ehm,
impractical. Having a deterministic tree walk is definitely a plus.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe
(cgroup_next_descendant_pre);
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
descendant
iterators, -post_create() can be used to implement reliable state
inheritance. It will be explained with the descendant iterators.
Thanks
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On Wed 07-11-12 09:01:18, Tejun Heo wrote:
Hello, Michal.
On Wed, Nov 07, 2012 at 05:54:57PM +0100, Michal Hocko wrote:
+struct cgroup *cgroup_next_descendant_pre(struct cgroup *pos,
+ struct cgroup *cgroup)
+{
+ struct cgroup *next
-by: Sha Zhengju handai@taobao.com
Cc: Michal Hocko mho...@suse.cz
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: David Rientjes rient...@google.com
Cc: Andrew Morton a...@linux-foundation.org
---
mm/memcontrol.c | 71
---
mm
scan through more tasks currently and most of them
are not relevant but then you would need to exclude task_in_mem_cgroup
from oom_unkillable_task and that would be more code churn than the
win.
Signed-off-by: Sha Zhengju handai@taobao.com
Cc: Michal Hocko mho...@suse.cz
Cc: KAMEZAWA Hiroyuki
On Wed 07-11-12 14:10:25, Andrew Morton wrote:
On Tue, 16 Oct 2012 00:04:08 +0200
Michal Hocko mho...@suse.cz wrote:
As Kosaki correctly pointed out, the glogal reclaim doesn't have this
issue because we _do_ swap on swappinnes==0 so the swap space has
to be considered. So the v2 is just
On Wed 07-11-12 14:53:40, Andrew Morton wrote:
On Wed, 7 Nov 2012 23:46:40 +0100
Michal Hocko mho...@suse.cz wrote:
Realistically, is anyone likely to hurt from this?
The primary motivation for the fix was a real report by a customer.
Describe it please and I'll copy
this rather than css_get_next
after this gets into the next tree so that it can fly via Andrew.
Reviewed-by: Michal Hocko mho...@suse.cz
Just a minor knit. You are talking about a config propagation while I
would consider state propagation more clear and less confusing. Config
is usually stable
-by: Michal Hocko mho...@suse.cz
---
kernel/cgroup_freezer.c | 41 +++--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index bedefd9..975b3d8 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel
with hierarchy handling later on.
This patch doesn't introduce any behavior change.
Signed-off-by: Tejun Heo t...@kernel.org
Makes sense
Reviewed-by: Michal Hocko mho...@suse.cz
---
kernel/cgroup_freezer.c | 48 ++--
1 file changed, 30 insertions(+), 18
to use freezer_state_flags enum rather than
unsigned int for the state. I would even expect gcc to complain about
that but it looks like -fstrict-enums is c++ specific (so long enum
safety).
Anyway
Reviewed-by: Michal Hocko mho...@suse.cz
---
kernel/cgroup_freezer.c | 60
On Tue 06-11-12 09:03:54, Michal Hocko wrote:
On Mon 05-11-12 16:28:37, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:35 +0400
Glauber Costa glom...@parallels.com wrote:
+static __always_inline struct kmem_cache *
+memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp)
I
state to determine what the problem is.
I really wondering if there is any case that can pass
root_mem_cgroup down here.
No it cannot because the root cgroup doesn't have any limit so we cannot
trigger memcg oom killer.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line
interested
in. Could you also update Documentation/cgroups/freezer-subsystem.txt to
clarify the intended usage?
Minor nit. Same as mentioned in the previous patch freezer_apply_state
should get enum freezer_state_flags state parameter.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Michal Hocko
is moved from
freezer_destroy() to the new freezer_pre_destroy() for consistency.
This patch doesn't introduce any noticeable behavior change.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Michal Hocko mho...@suse.cz
---
kernel/cgroup_freezer.c | 42
)
So A, C are thawed while B is frozen. Or am I missing something which
would prevent from this kind of race?
The easy fix is to move spin_unlock_irq(freezer-lock); after
rcu_read_unlock.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu 08-11-12 12:05:13, Michal Hocko wrote:
On Tue 06-11-12 09:03:54, Michal Hocko wrote:
On Mon 05-11-12 16:28:37, Andrew Morton wrote:
On Thu, 1 Nov 2012 16:07:35 +0400
Glauber Costa glom...@parallels.com wrote:
+static __always_inline struct kmem_cache
On Thu 08-11-12 06:39:52, Tejun Heo wrote:
Hello, Michal.
On Thu, Nov 08, 2012 at 11:39:28AM +0100, Michal Hocko wrote:
On Sat 03-11-12 01:38:32, Tejun Heo wrote:
freezer-state was an enum value - one of THAWED, FREEZING and FROZEN.
As the scheduled full hierarchy support requires more
On Thu 08-11-12 06:18:48, Tejun Heo wrote:
Hello, Michal.
On Thu, Nov 08, 2012 at 03:08:52PM +0100, Michal Hocko wrote:
This seems to be racy because parent-state access is not linearized.
Say we have parallel freeze and thawing on a tree like the following:
A
|
B
kill flags in the next patch.
Signed-off-by: David Rientjes rient...@google.com
Reviewed-by: Michal Hocko mho...@suse.cz
---
drivers/staging/android/lowmemorykiller.c | 16
fs/proc/base.c| 10 +-
include/linux/oom.h
-by: David Rientjes rient...@google.com
I didn't like the previous playing with the oom_score_adj and what you
propose looks much nicer.
Maybe s/oom_task_origin/task_oom_origin/ would be a better fit with
{set,clear}_current_oom_origin but I do not care much.
Reviewed-by: Michal Hocko mho...@suse.cz
On Thu 08-11-12 07:29:23, Tejun Heo wrote:
Hey, Michal.
On Thu, Nov 08, 2012 at 04:20:39PM +0100, Michal Hocko wrote:
So, in the above example in CPU2, (B-state FREEZING) test and
freezer_apply_state(C, false) can't be interleaved with the same
inheritance operation from CPU1
/: ...
Would it still fit in with your use case?
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
...@kernel.org
Reviewed-by: Tejun Heo t...@kernel.org
You probably meant Reviewed-by: Michal Hocko ;)
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Thu 08-11-12 10:04:17, Tejun Heo wrote:
On Thu, Nov 08, 2012 at 07:02:46PM +0100, Michal Hocko wrote:
On Thu 08-11-12 09:57:50, Tejun Heo wrote:
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Tejun Heo t...@kernel.org
You probably meant Reviewed-by: Michal Hocko
On Fri 19-10-12 12:11:52, Sha Zhengju wrote:
On 10/18/2012 11:32 PM, Michal Hocko wrote:
On Thu 18-10-12 21:51:57, Sha Zhengju wrote:
On 10/18/2012 07:56 PM, Michal Hocko wrote:
On Wed 17-10-12 01:14:48, Sha Zhengju wrote:
On Tuesday, October 16, 2012, Michal Hockomho...@suse.cz wrote
On Fri 19-10-12 17:33:18, Li Zefan wrote:
On 2012/10/17 21:30, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs
On Thu 18-10-12 15:16:54, Tejun Heo wrote:
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:45PM +0200, Michal Hocko wrote:
mem_cgroup_force_empty_list currently tries to remove all pages from
the given LRU. To prevent from temoporary failures (EBUSY returned by
mem_cgroup_move_parent
On Thu 18-10-12 15:41:48, Tejun Heo wrote:
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving
of this
whole series, but please do drop .__DEPRECATED_clear_css_refs from
memcg.
OK I will drop that one.
Acked-by: Tejun Heo t...@kernel.org
Do you still agree with the v2 based on Li's feedback?
Thanks
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux
: Michal Hocko mho...@suse.cz
Date: Wed, 17 Oct 2012 14:15:09 +0200
Subject: [PATCH] memcg: make mem_cgroup_reparent_charges non failing
Now that pre_destroy callbacks are called from within cgroup_lock and
the cgroup has been checked to be empty without any children then there
is no other way to fail
?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri 19-10-12 13:24:05, Tejun Heo wrote:
Hello, Michal.
On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:
On Thu 18-10-12 15:41:48, Tejun Heo wrote:
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy
?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
cgroup, this
will never happens.
Strange and it smells like a misconfiguration. Could you provide the
compllete setting for both controllers?
grep . -r /cgroup/
On Sat, Oct 20, 2012 at 12:04 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 17-10-12 18:23:34, gaoqiang wrote:
I looked up
is basically pointless as it
cannot be reached...
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
CONFIG_MEMORY_HOTREMOVE which causes a linkage error.
The function, although not used outside of MEMORY_{HOTPLUT,HOTREMOVE},
seems like universal enough so let's keep it at its current location
and only remove the HOTREMOVE guard.
Signed-off-by: Michal Hocko mho...@suse.cz
Cc: David Rientjes rient
but mentioning memory controller then might be misleading... It
seems that the only factor in your load is the cpu controller.
And please stop top-posting. It makes the discussion messy.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
AM, Qiang Gao gaoqiangs...@gmail.com wrote:
information about the system is in the attach file information.txt
I can not reproduce it in the upstream 3.6.0 kernel..
On Sat, Oct 20, 2012 at 12:04 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 17-10-12 18:23:34, gaoqiang wrote:
I looked
On Tue 23-10-12 18:10:33, Qiang Gao wrote:
On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko mho...@suse.cz wrote:
On Tue 23-10-12 15:18:48, Qiang Gao wrote:
This process was moved to RT-priority queue when global oom-killer
happened to boost the recovery of the system..
Who did that? oom
On Tue 23-10-12 18:14:28, Wen Congyang wrote:
At 10/23/2012 05:37 PM, Michal Hocko Wrote:
340175b7 (mm/hotplug: free zone-pageset when a zone becomes empty)
introduced zone_pcp_reset and hided it inside CONFIG_MEMORY_HOTREMOVE.
The function is since 506e5fb7 (memory-hotplug: allocate zone's
'
Caused by memory-hotplug-allocate-zones-pcp-before-onlining-pages.patch.
And fixed by. Andrew either fold this one in to the above one or keep it
separate what works better with you.
---
From e8d79e446b00e57c195c59570df0f2ec435ca39d Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date: Tue
On Tue 23-10-12 16:45:46, Andrew Morton wrote:
On Fri, 12 Oct 2012 14:57:08 +0200
Michal Hocko mho...@suse.cz wrote:
Hi,
I would like to resurrect the following Dave's patch. The last time it
has been posted was here https://lkml.org/lkml/2010/9/16/250 and there
didn't seem to be any
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
1 - 100 of 20557 matches
Mail list logo
