for obvious reasons but hopefuly we will get some feedback at
least.
Thanks Tejun for doing this. We needed it for a long time.
--
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 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
signed index == -1.
It would be nice to describe what is memcg_params.id intended 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
--
To unsubscribe from this list:
_match_cgroup(const struct mm_struct *mm, const
> struct mem_cgroup *cgroup)
>
> 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(cg
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 h
Sorry Andrea, that simply is impractical.
>
> The first thing Andrew's patch series does is include linux-next,
> therefore every THP and MM patch in his series is against linux-next.
FWIW there is also a pure -mm (non-rebased) git tree at
http://git.kernel.org/?p=linux/kernel/git
t making things simpler in general, cgroup
> is riddled with mis-designed complexities and memcg seems to be
> leading the charge at times.
Yes this is an evolution and it seems that we are slowly getting there.
>
> Thanks.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this lis
o the memcg limit 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.
outside 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
Cc: David Rientjes
Cc: Jiang
> oom.
Yes 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
23, 2012 at 9:05 AM, Qiang Gao 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 wrote:
On Tue 23-10-12 18:10:33, Qiang Gao wrote:
> On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko 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.
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
parate what works better with you.
---
>From e8d79e446b00e57c195c59570df0f2ec435ca39d Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 23 Oct 2012 11:07:11 +0200
Subject: [PATCH] mm: make zone_pcp_reset independ on MEMORY_HOTREMOVE
340175b7 (mm/hotplug: free zone->pageset when a zone bec
On Tue 23-10-12 16:45:46, Andrew Morton wrote:
> On Fri, 12 Oct 2012 14:57:08 +0200
> Michal Hocko 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
On Wed 24-10-12 11:44:17, Qiang Gao wrote:
> On Wed, Oct 24, 2012 at 1:43 AM, Balbir Singh wrote:
> > On Tue, Oct 23, 2012 at 3:45 PM, Michal Hocko wrote:
> >> On Tue 23-10-12 18:10:33, Qiang Gao wrote:
> >>> On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko wrote:
&g
!CONFIG_TRACING both declares and defines (empty) trace_printk.
The first one is not redundant so it can be removed.
Signed-off-by: Michal Hocko
---
include/linux/kernel.h |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux
On Wed 24-10-12 12:54:39, Andrew Morton wrote:
> On Wed, 24 Oct 2012 08:29:45 +0200
> Michal Hocko wrote:
[...]
> hmpf. This patch worries me. If there are people out there who are
> regularly using drop_caches because the VM sucks, it seems pretty
> obnoxious of us to go dum
t distribution kernels.
I am just worried it needs debugfs mounted and my recollection is that
this has some security implications so there might be some pushback on
mounting it on production systems which would defeat the primary
motivation.
Maybe this concern is not that important wrt. excessive log
y realize that drop_caches is the reason our
> caches went away, not some anomalous VM activity. A secondary goal is
> to tell the user: "Hey, maybe this isn't something you want to be doing
> all the time."
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send th
On Wed 24-10-12 12:25:35, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Oct 22, 2012 at 12:30:21PM +0200, Michal Hocko wrote:
> > > > We can still fail inn #3 without this patch becasuse there are is no
> > > > guarantee that a new task is attached to the group. A
On Thu 25-10-12 10:42:20, Tejun Heo wrote:
> Hey, Michal.
>
> On Thu, Oct 25, 2012 at 04:37:56PM +0200, Michal Hocko wrote:
> > I am not sure I understand you here. So are you suggesting
> > s/BUG_ON/WARN_ON_ONCE/ in this patch?
>
> Oh, no, I meant that we can do upto
groups core change
because now we know that nobody will interfere with us so we can drop
those empty && no child condition.
See the specific patches for the changelogs.
Michal Hocko (6):
memcg: split mem_cgroup_force_empty into reclaiming and reparenting parts
memcg: root_cgro
can always move charges upwards.
Signed-off-by: Michal Hocko
Reviewed-by: Tejun Heo
---
mm/memcontrol.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 07d92b8..916132a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
t have any functional changes.
Signed-off-by: Michal Hocko
Reviewed-by: Tejun Heo
---
mm/memcontrol.c | 72 ---
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 795e525..07d92b8 10064
Now that pre_destroy callbacks are called from the context where neither
any task can attach the group nor any children group can be added there
is no other way to fail from hugetlb_pre_destroy.
Signed-off-by: Michal Hocko
Reviewed-by: Tejun Heo
---
mm/hugetlb_cgroup.c | 11 +++
1
x27; are marked dead already.
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 5a1d584..34284b8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3763,14 +3763,12
anges since v1
- Li Zefan pointed out that mem_cgroup_pre_destroy cannot be called with
cgroup_lock held
Signed-off-by: Michal Hocko
---
kernel/cgroup.c | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 79
This means that __DEPRECATED_clear_css_refs has lost
its meaning and it can be removed.
Changes since v2
- remove __DEPRECATED_clear_css_refs
Changes since v1
- use kerndoc
- be more specific about mem_cgroup_move_parent possible failures
Signed-off-by: Michal Hocko
Reviewed-by: Tejun Heo
---
mm/memc
{
> + for_each_node_state(nid, N_MEMORY) {
> unsigned long start_pfn, end_pfn;
>
> start_pfn = node_start_pfn(nid);
This will call init_section_page_cgroup(pfn, nid) later which allocates
page_cgroup descriptors which are not movable. Or is there any co
_rmdir() will see more cleanup soon.
>
> Signed-off-by: Tejun Heo
Looks good to me and the diffstat is really encouraging
Reviewed-by: Michal Hocko
with a minor note bellow
> ---
> include/linux/cgroup.h | 12
> kernel/cgroup.c| 159
> -
hink it's better to
> simply unexport it.
>
> Signed-off-by: Tejun Heo
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
Few questions/suggestions below but it looks good in general to me.
Reviewed-by: Michal Hocko
>
k unnecessary.
>
> Do it anyway 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
Looks good. Just a nit bellow
Reviewed-by: Michal Hocko
> ---
>
safely assume that ->pre_destroy()
> will only be called only once for a given cgroup and, once
> ->pre_destroy() is called, the cgroup will stay dormant till it's
> destroyed.
>
> Signed-off-by: Tejun Heo
Reviewed-by: Michal Hocko
> ---
> kernel/cgroup.c | 41 ++
e gone, CGRP_WAIT_ON_RMDIR is
> unnecessary. Remove 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
> Cc: Michal Hocko
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
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
> Cc: Vivek Goy
/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.kerne
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_destr
t;pre_destroy) {
int ret = ss->pre_destroy(cgrp);
clear_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags);
return ret;
}
>
> mutex_lock(&cgroup_mutex);
> parent = cgrp->parent;
[...]
--
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();
> > > -
&g
t to hang in css_tryget from 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 "unsu
o I would
put it out of way as it doesn't give us anything and as I've already
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
M
On Wed 31-10-12 13:11:02, Tejun Heo wrote:
> Hello,
>
> On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko 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
n.
Much better. Thanks a lot!
--
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 Wed 31-10-12 13:14:07, Tejun Heo wrote:
> Hey, Michal.
>
> On Wed, Oct 31, 2012 at 1:12 PM, Michal Hocko 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
> &
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
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
> Cc: Vivek
gt; + * called with cgroup_mutex unlocked. See 3fa59dfbc3 ("cgroup: fix
> + * potential deadlock in pre_destroy") for details.
> + */
> + mutex_unlock(&cgroup_mutex);
> + for_each_subsys(cgrp->root, ss)
> + if (ss->pre_destroy)
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_dest
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 stri
On Thu 01-11-12 07:52:24, Tejun Heo wrote:
> Hey, Michal.
>
> On Thu, Nov 1, 2012 at 2:16 AM, Michal Hocko 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 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 wrote:
> > > I am not sure I understand. What does deactivate_super has to do with
> > > the a
ne additional mem access&cmp&je 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
Than
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).
e'll have shrunk a lot of the pending caches, and we will have less
> pages to reparent. But we only reparent pages in the lru anyway, and
> then expect kmem and remaining umem to match. So *in theory* it should
> be fine.
>
> Where can I grab your final tree so I ca
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
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
pages
nfs: disable data cache revalidation for swapfiles
nfs: enable swap on NFS
nfs: prevent page allocator recursions with swap over NFS.
swapfile: avoid dereferencing bd_disk during swap_entry_free for network
storage
mm-add-get_kernel_page-for-pinning-of-kernel-addr
On Thu 26-07-12 14:31:50, Rik van Riel wrote:
> On 07/20/2012 10:36 AM, Michal Hocko wrote:
>
> >--- a/arch/x86/mm/hugetlbpage.c
> >+++ b/arch/x86/mm/hugetlbpage.c
> >@@ -81,7 +81,12 @@ static void huge_pmd_share(struct mm_struct *mm, unsigned
> >long addr, pud_t *
alled from unmap_mapping_range(). However, hugetlbfs
> should never be in this path. It has its own setattr and truncate handlers
> where are the paths that use unmap_mapping_range().
>
> Unless Aneesh has another reason for the patch, it should be reverted
> to preserve hugetlb p
ary
> + * is to clear it before releasing the i_mmap_mutex. This works
> + * because in the context this is called, the VMA is about to be
> + * destroyed and the i_mmap_mutex is held.
> + */
> + vma->vm_flags &= ~VM_MAYSHARE;
> +}
> +
--
Michal Ho
nged, 141 insertions(+), 74 deletions(-)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
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/
Please note that memcg oom can happen much more often than the global
oom so we should print only the important information.
Some more questions/notes below.
In short, I think the patch should be dropped.
> Signed-off-by: Sha Zhengju
> Cc: KAMEZAWA Hiroyuki
> Cc: Michal Hocko
taobao.com are
>
> mm-oom-introduce-helper-function-to-process-threads-during-scan.patch
> mm-memcg-introduce-own-oom-handler-to-iterate-only-over-its-own-threads.patch
> memcg-oom-provide-more-info-while-memcg-oom-happening.patch
> memcg-oom-clarify-some-oom-dump-messages.patch
&g
different candidates for sharing for the same
address.
Thanks!
> These two processes are not poing to the same data page but are not sharing
> page tables because the opportunity was missed. When either process later
> forks, the src_pte == dst pte is potentially insufficient. As
(dis)advantages of both approaches
later.
Thanks!
---
>From 8cbf3bd27125fc0a2a46cd5b1085d9e63f9c01fd Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 31 Jul 2012 15:00:26 +0200
Subject: [PATCH] mm: hugetlbfs: Correctly populate shared pmd
Each page mapped in a processes address space must be correctly
accou
On Thu 20-09-12 15:33:23, David Rientjes wrote:
> On Thu, 20 Sep 2012, Michal Hocko wrote:
>
> > Yes printk_once is an alternative but I really wanted to have this as
> > much visible as possible. People tend to react to stack traceces more
> > and this one will trigger on
em
> is effectively unlimited.
>
> People who want to track kernel memory but not limit it, can set this
> limit to a very high number (like RESOURCE_MAX - 1page - that no one
> will ever hit, or equal to the user memory)
>
> Signed-off-b
s ]
> [ v4: reworked Used bit handling and surroundings for more clarity ]
>
> Signed-off-by: Glauber Costa
> CC: Christoph Lameter
> CC: Pekka Enberg
> CC: Michal Hocko
> CC: Kamezawa Hiroyuki
> CC: Johannes Weiner
> ---
> include/linux/memcontrol.h
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;
> &g
On Mon 29-10-12 17:48:00, Glauber Costa wrote:
> On 10/26/2012 03:37 PM, Michal Hocko wrote:
> > The root cgroup cannot be destroyed so we never hit it down the
> > mem_cgroup_pre_destroy path and mem_cgroup_force_empty_write shouldn't
> > even try to do anyth
On Mon 29-10-12 17:58:45, Glauber Costa wrote:
>
> >
> > Changes since v1
> > - use kerndoc
> > - be more specific about mem_cgroup_move_parent possible failures
> >
> > Signed-off-by: Michal Hocko
> > Reviewed-by: Tejun Heo
> Reviewed-by: Glau
On Mon 29-10-12 18:06:34, Glauber Costa wrote:
> On 10/29/2012 06:04 PM, Glauber Costa wrote:
> > On 10/26/2012 03:37 PM, Michal Hocko wrote:
> >> Now that mem_cgroup_pre_destroy callback doesn't fail (other than a race
> >> with a task attach resp. child group app
node_nr = mem_cgroup_node_nr_lru_pages(memcg, nid,
> BIT(LRU_UNEVICTABLE));
> seq_printf(m, " N%d=%lu", nid, node_nr);
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 5ddad0c..c1054ad 100644
> --- a/mm/page_cgroup.c
>
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
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.
> > > &
robably mentioned in the
patch description but I do not see any way around (except for hacks like
sched_setscheduler for the current which is, ehm...) and still keep
do_not_fail contract here.
Can we consider this as a corner case (it is much easier to kill a
machine with SCHED_FIFO than this anyw
th which will replace #4.
> #5 and #6 should be stackable on top.
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 abou
On Tue 27-08-13 16:52:27, Andrew Morton wrote:
> A git tree which contains the memory management portion of this tree is
> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> by Michal Hocko. It contains the patches which are between the
> "#NEXT_PATC
;> 10,
> @@ -1602,9 +1598,10 @@ done:
> pr_info("Memory cgroup stats");
>
> rcu_read_lock();
> - ret = cgroup_path(iter->css.cgroup, memcg_name, PATH_MAX);
> + ret = cgroup_path(iter->css.cgroup, iter->name,
>
ned long address, unsigned int fault)
> {
> - /*
> - * Pagefault was interrupted by SIGKILL. We have no reason to
> - * continue pagefault.
> - */
> - if (fatal_signal_pending(current)) {
> - if (!(fault & VM_FAULT_RETRY))
> -
On Tue 09-07-13 15:00:17, Michal Hocko wrote:
> On Mon 24-06-13 16:13:45, Johannes Weiner wrote:
> > Hi guys,
> >
> > On Sat, Jun 22, 2013 at 10:09:58PM +0200, azurIt wrote:
> > > >> But i'm sure of one thing - when problem occurs, nothing is able to
&
On Tue 09-07-13 15:08:08, Michal Hocko wrote:
> On Tue 09-07-13 15:00:17, Michal Hocko wrote:
> > On Mon 24-06-13 16:13:45, Johannes Weiner wrote:
> > > Hi guys,
> > >
> > > On Sat, Jun 22, 2013 at 10:09:58PM +0200, azurIt wrote:
> > > > >> Bu
On Mon 08-07-13 01:42:24, azurIt wrote:
> > CC: "Michal Hocko" , linux-kernel@vger.kernel.org,
> > linux...@kvack.org, "cgroups mailinglist" ,
> > "KAMEZAWA Hiroyuki"
> >On Fri, Jul 05, 2013 at 09:02:46PM +0200, azurIt wrote:
> >&g
c b/kernel/exit.c
index e6e01b9..ad472e0 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -895,6 +895,7 @@ NORET_TYPE void do_exit(long code)
profile_task_exit(tsk);
+ WARN_ON(current->memcg_oom.wait_on_memcg);
WARN_ON(blk_needs_flush_plug(tsk));
if (unlikely(i
posted a patch two days ago fixing some missing conversions in
> the XFS side. AFAIK, Andrew hasn't yet picked the patch.
Could you point me to those patches, please?
> Are you running with that patch applied?
I am currently running with "list_lru: fix broken LRU_RETRY behaviour&q
On Wed 10-07-13 01:40:06, Jiri Kosina wrote:
> On Thu, 4 Jul 2013, Michal Hocko wrote:
[...]
> > >From 5f089c0b2a57ff6c08710ac9698d65aede06079f Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Thu, 4 Jul 2013 17:15:54 +0200
> > Subject: [PATCH] mm: Hon
On Wed 10-07-13 12:31:39, Dave Chinner wrote:
> On Mon, Jul 08, 2013 at 02:53:52PM +0200, Michal Hocko wrote:
[...]
> > Hmm, it seems I was too optimistic or we have yet another issue here (I
> > guess the later is more probable).
> >
> > The weekend testing got stuck
he list, thus pre-mature OOM killer. See
e62e384e9d (memcg: prevent OOM with too many dirty pages) for more
details. The original patch relied on may_enter_fs but that check
disappeared by later changes by c3b94f44fc (memcg: further prevent OOM
with too many dirty pages).
--
Michal Hocko
SUSE Labs
-
On Wed 10-07-13 09:31:42, Joonsoo Kim wrote:
> On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote:
> > On Thu 04-07-13 13:24:50, Joonsoo Kim wrote:
> > > On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote:
> > > > On 07/03/2013 11:51 PM, Zhang Ya
. I do see why oom_control
is a good fit for you (and I thought about it as well - it is really
ironic that I thought you would hate the idea when I mentioned that at
LSF) but once we allow that we will have to live with that for ever
which might turn out to be problem so better not hurry there.
F
On Wed 10-07-13 18:55:33, Joonsoo Kim wrote:
> On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote:
> > On Wed 10-07-13 09:31:42, Joonsoo Kim wrote:
> > > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote:
[...]
> > > > Which benchmark
also doesn't seem to be any new handle_mm_fault call sites.
But I cannot tell there aren't other code paths which would lead to a
memcg charge, thus oom, without proper FAULT_FLAG_KERNEL handling.
--
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 Thu 11-07-13 12:26:34, Dave Chinner wrote:
> On Wed, Jul 10, 2013 at 10:06:05AM +0200, Michal Hocko wrote:
> > On Wed 10-07-13 12:31:39, Dave Chinner wrote:
> > [...]
> > > > 20761 [] xlog_grant_head_wait+0xdd/0x1a0 [xfs]
> > > >
you are referring to as a stuck situation. Is pid
8453 the task you have seen consuming the CPU? If yes, then we would
need a stack for that task to find out what is going on.
Other than that nothing really suspicious in the log AFAICS.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send
[Sorry for the late reply. I am in pre-long-vacation mode trying to
clean up my desk]
On Thu 12-09-13 08:59:38, Johannes Weiner wrote:
> On Mon, Sep 09, 2013 at 02:56:59PM +0200, Michal Hocko wrote:
[...]
> > Hmm, wait a second. I have completely forgot about the kmem charging
> >
>extremely helpful.
>
> I'm afraid it won't be possible as server is completely not responding
> when it happens. Anyway, i don't think it was a fault of one process
> or one user.
You can use sysrq+l via serial console to see tasks hogging the CPU or
sysrq+t to see all
r accessing my serial consoles exported by
the multiplicator or KVM and it can send sysrq via ctrl+t (Send
Break). Check your serial console setup.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.k
sole setup.
>
>
>
> I'm using Raritan KVM and i created keyboard macro 'sysrq + l' resp.
> 'sysrq + t'. I'm also unable to use it on my local PC. Maybe it needs
> to be enabled somehow?
Probably yes. echo 1 > /proc/sys/kernel/sysrq should en
On Fri 13-09-13 12:17:09, Johannes Weiner wrote:
> On Fri, Sep 13, 2013 at 04:49:53PM +0200, Michal Hocko wrote:
> > On Fri 06-09-13 15:23:11, Johannes Weiner wrote:
[...]
> > > I would really like to deprecate soft limits and introduce something
> > > new that has t
is
waiting for which requires to know a deeper context.
--
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/
201 - 300 of 11648 matches
Mail list logo
