On Wed 27-03-13 15:19:24, Naoya Horiguchi wrote:
> On Wed, Mar 27, 2013 at 02:52:50PM +0100, Michal Hocko wrote:
> > On Tue 26-03-13 16:59:40, Aneesh Kumar K.V wrote:
> > > Naoya Horiguchi writes:
> > [...]
> > > > diff --git v3.9-rc3.orig/mm/memory-failure.c
ng in a stuttered playback ;).
>
> No, this is still terrible. I was now updating a kernel in a VM and had
> problems to even move with cursor.
:/
> There was still 1.2G used by I/O cache.
Could you collect /proc/zoneinfo and /proc/vmstat (say in 1 or 2s
intervals)?
--
Michal Hocko
SUSE
On Fri 29-03-13 10:56:00, Aneesh Kumar K.V wrote:
> Michal Hocko writes:
[...]
> > Little bit offtopic:
> > Btw. hugetlb migration breaks to charging even before this patchset
> > AFAICS. The above put_page should remove the last reference and then it
> > will u
eserved_vm counter". This looks to me a serious regression,
> so let's fix it.
>
> Signed-off-by: Naoya Horiguchi
> Cc: Konstantin Khlebnikov
Acked-by: Michal Hocko
> ---
> fs/hugetlbfs/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
se is_hugetlb_entry_hwpoisoned
instead?
--
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/
llows
> __mem_cgroup_try_charge() to succeed so that the process may exit. This
> makes the memcg oom killer exemption for TIF_MEMDIE tasks, now
> immediately granted for processes with pending SIGKILLs and those in the
> exit path, to be equivalent to what is done for the global oom
d section.
>
> This also removes a bogus comment above __memcg_create_cache_enqueue().
>
> Signed-off-by: Li Zefan
Looks good to me.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 63
> ++---
> 1 file changed, 33 in
tely not many.
>
> -ilia
> --
> 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.tu
Forwarding off-list email
On Fri 29-03-13 18:24:01, Aneesh Kumar K.V wrote:
> Michal Hocko writes:
>
> > On Fri 29-03-13 10:56:00, Aneesh Kumar K.V wrote:
> >> Michal Hocko writes:
> > [...]
> >> > Little bit offtopic:
> >> > Btw. hugetlb mig
iput(container_of(dev->dev_mapping, struct inode, i_data));
> dev->dev_mapping = old_mapping;
> mutex_unlock(&dev->struct_mutex);
--
1.8.1.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/
On Mon 01-04-13 10:39:00, Li Zefan wrote:
> This might cause use-after-free bug.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
> ---
>
> found when reading the code.
>
> ---
> mm/memcontrol.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
1f0
> [ 207.273309] [] device_unregister+0x22/0x60
> [ 207.273321] [] mce_cpu_callback+0x15e/0x1ad
> [ 207.273332] [] notifier_call_chain+0x72/0x130
> [ 207.273344] [] __raw_notifier_call_chain+0xe/0x10
> [ 207.273356] [] _cpu_down+0x1d6/0x350
> [ 207.273368] [] ? cpu_hotplug_drive
On Tue 31-07-12 22:45:43, Larry Woodman wrote:
> On 07/31/2012 04:06 PM, Michal Hocko wrote:
> >On Tue 31-07-12 13:49:21, Larry Woodman wrote:
> >>On 07/31/2012 08:46 AM, Mel Gorman wrote:
> >>>Fundamentally I think the problem is that we are not correctly detectin
On Wed 01-08-12 10:20:36, Michal Hocko wrote:
> On Tue 31-07-12 22:45:43, Larry Woodman wrote:
> > On 07/31/2012 04:06 PM, Michal Hocko wrote:
> > >On Tue 31-07-12 13:49:21, Larry Woodman wrote:
> > >>On 07/31/2012 08:46 AM, Mel Gorman wrote:
> > >>>Fun
Hi Larry,
On Wed 01-08-12 11:06:33, Larry Woodman wrote:
> On 08/01/2012 08:32 AM, Michal Hocko wrote:
> >
> >I am really lame :/. The previous patch is wrong as well for goto out
> >branch. The updated patch as follows:
> This patch worked fine Michal!
Thanks for the g
On Thu 02-08-12 08:37:57, Mel Gorman wrote:
> On Thu, Aug 02, 2012 at 09:19:34AM +0200, Michal Hocko wrote:
[...]
> > On the other hand, mine is more coupled with the sharing code so it
> > makes the code easier to follow and also makes the sharing more
> > effective because
On Thu 02-08-12 14:33:10, Mel Gorman wrote:
> On Thu, Aug 02, 2012 at 02:36:58PM +0200, Michal Hocko wrote:
> > On Thu 02-08-12 08:37:57, Mel Gorman wrote:
> > > On Thu, Aug 02, 2012 at 09:19:34AM +0200, Michal Hocko wrote:
> > [...]
> > > > On the other hand, m
also
highers chances for sharing.
---
>From 68e132e56793073ba9a6efc20f8fcc7de0f701b6 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 correc
ma, vma, addr, idx);
> + saddr = page_table_shareable(svma, vma, addr,
> + idx * (PMD_SIZE/PAGE_SIZE));
Why not just fixing page_table_shareable as well rather than playing
tricks like this?
> if (saddr) {
> spt
a, addr);
> +
> mutex_lock(&mapping->i_mmap_mutex);
> - vma_prio_tree_foreach(svma, &iter, &mapping->i_mmap, idx, idx) {
> + vma_prio_tree_foreach(svma, &iter, &mapping->i_mmap, hp_idx, hp_idx) {
> if (svma == vma)
>
On Mon 06-08-12 21:37:45, Hillf Danton wrote:
> On Mon, Aug 6, 2012 at 9:24 PM, Michal Hocko wrote:
> > On Sat 04-08-12 14:08:31, Hillf Danton wrote:
> >> The computation of page offset index is incorrect to be used in scanning
> >> prio tree, as huge page offset is
should we use
page_idx here?
> if (page_is_buddy(higher_page, higher_buddy, order + 1)) {
> list_add_tail(&page->lru,
>
> &zone->free_area[order].free_list[migratetype]);
> --
> 1.7.5.4
--
Mi
so good to mention that this is a regression
since 43506fad (mm/page_alloc.c: simplify calculation of combined index
of adjacent buddy lists). IIUC this basically disables the heuristic
because page_is_buddy will fail for order+1, right?
Maybe 2.6.38+ stable candidate, then.
Could you repost with the full changelog, please?
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 at http://www.tux.org/lkml/
HREAD_INFO_ALLOCATOR in general) which
doesn't allocate thread_info at all?
> return NULL;
> }
>
> --
> 1.7.11.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@v
On Thu 23-08-12 16:33:12, Michal Hocko wrote:
> On Thu 23-08-12 17:08:46, Glauber Costa wrote:
> > When we want to duplicate a new process, dup_task_struct() will undergo
> > a series of allocations. If alloc_thread_info_node() fails, we call
> > free_task_struct() and return
On Thu 23-08-12 16:38:50, Michal Hocko wrote:
> On Thu 23-08-12 16:33:12, Michal Hocko wrote:
> > On Thu 23-08-12 17:08:46, Glauber Costa wrote:
> > > When we want to duplicate a new process, dup_task_struct() will undergo
> > > a series of allocations. If alloc_thread
[] ia64_bad_break+0x3d0/0x6e0
> sp=e0070a91fb90 bsp=e0070a9114f0
> [] ia64_native_leave_kernel+0x0/0x270
> sp=e0070a91fc20 bsp=e0070a9114f0
> [] offline_pages+0x210/0xee0
> sp=e00
into
> the pool.
>
> This patch adds a new architecture hook, arch_clear_hugepage_flags, so
> that architectures which rely on the page flags being in a particular
> state for fresh allocations can adjust the flags accordingly when a
> page is freed into the pool.
>
> Cc:
t; Signed-off-by: Gavin Shan
Other than that
Reviewed-by: Michal Hocko
> ---
> mm/page_alloc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cdef1d4..642cd62 100644
> --- a/mm/page_alloc.c
> ++
On Fri 24-08-12 17:08:36, Li Haifeng wrote:
> 2012/8/24 Michal Hocko :
> > On Fri 24-08-12 10:08:20, Li Haifeng wrote:
> > [...]
> >> Subject: [PATCH] Fix the page address of higher page's buddy calculation
> >>
> >> Calculate the page
---
>From 3c18a5330f37a3bb2a622d63b1755dd4d8682fd3 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Fri, 14 Sep 2012 13:56:32 +0200
Subject: [PATCH] memcg: move mem_cgroup_is_root upwards
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
kmem code uses this function and it is better to no
‘max77693_irq_init’:
drivers/mfd/max77693-irq.c:286: error: implicit declaration of function
‘irq_domain_add_linear’
Signed-off-by: Michal Hocko
---
drivers/mfd/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 92144ed..28ad9a5 100644
--- a
memcg specific patch.
On Fri 14-09-12 17:03:06, Michal Hocko wrote:
> I am currently planning to add a warning to most of the currenly
> maintained distributions to have as big coverage as possible. No default
> switch for obvious reasons but hopefuly we will get some feedback at
> leas
>From 34be56e3e7e4f9c31381ce35247e0a0b7f972874 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 4 Sep 2012 15:55:03 +0200
Subject: [PATCH] memcg: warn on deeper hierarchies with use_hierarchy==0
The memory controller supports both hierarchical and non-hierarchical
behavior which
>From 9364396ddc0c8843fce3a7fda0255b39ba7e4f31 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 4 Sep 2012 15:55:03 +0200
Subject: [PATCH] memcg: warn on deeper hierarchies with use_hierarchy==0
The memory controller supports both hierarchical and non-hierarchical
behavior which
Should apply to 3.4 and later as well
---
>From cbfc6f1cdb4d8095003036c84d250a391054f971 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 4 Sep 2012 15:55:03 +0200
Subject: [PATCH] memcg: warn on deeper hierarchies with use_hierarchy==0
The memory controller supports both hierarchical
On Wed 19-09-12 12:38:18, David Rientjes wrote:
> On Wed, 19 Sep 2012, Michal Hocko wrote:
>
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index f99f599..b61c34b 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -3106,6 +3106,11 @@ me
On Tue 07-08-12 17:03:37, Will Deacon wrote:
>
>
> On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
> > On Thu 12-07-12 12:26:45, Will Deacon wrote:
> > > Well, the comment in linux/page-flags.h does state that:
> > >
> > > * PG_arch_1
On Fri 03-08-12 15:32:35, Michal Hocko wrote:
> On Fri 03-08-12 20:56:45, Hillf Danton wrote:
> > The computation of page offset index is open coded, and incorrect, to
> > be used in scanning prio tree, as huge page offset is required, and is
> > fixed with the well defined
On Fri 10-08-12 20:07:12, Hillf Danton wrote:
> On Fri, Aug 10, 2012 at 5:48 PM, Michal Hocko wrote:
> > On Fri 03-08-12 15:32:35, Michal Hocko wrote:
> >> On Fri 03-08-12 20:56:45, Hillf Danton wrote:
> >> > The computation of page offset index is open coded, and i
On Fri 10-08-12 20:37:20, Hillf Danton wrote:
> On Fri, Aug 10, 2012 at 8:27 PM, Michal Hocko wrote:
> >
> > I guess you mean unmap_ref_private and that has been changed by you
> > (0c176d5 mm: hugetlb: fix pgoff computation when unmapping page from
> > vma)... I
[CCing Kamezawa and David]
On Fri 10-08-12 20:53:36, Hillf Danton wrote:
> On Fri, Aug 10, 2012 at 8:51 PM, Michal Hocko wrote:
> > On Fri 10-08-12 20:37:20, Hillf Danton wrote:
> >> On Fri, Aug 10, 2012 at 8:27 PM, Michal Hocko wrote:
> >> >
> >> > I
On Fri 10-08-12 21:21:15, Hillf Danton wrote:
> On Fri, Aug 10, 2012 at 9:16 PM, Michal Hocko wrote:
> > Subject: [PATCH] hugetlb: do not use vma_hugecache_offset for
> > vma_prio_tree_foreach
> >
> > 0c176d5 (mm: hugetlb: fix pgoff computation when unmapping pag
igned-off-by: Suleiman Souhlal
> Signed-off-by: Glauber Costa
> Acked-by: David Rientjes
> Acked-by: Kamezawa Hiroyuki
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 28 ++--
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/mm
p_mask, batch, nr_pages,
> + oom_check);
> switch (ret) {
> case CHARGE_OK:
> break;
> --
> 1.7.11.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a
lauber Costa
> CC: Michal Hocko
> CC: Johannes Weiner
> Acked-by: Kamezawa Hiroyuki
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
On Sat 11-08-12 01:49:25, KAMEZAWA Hiroyuki wrote:
> (2012/08/11 0:42), Michal Hocko wrote:
> >On Thu 09-08-12 17:01:10, Glauber Costa wrote:
> >[...]
> >>@@ -2317,18 +2318,18 @@ static int mem_cgroup_do_charge(struct mem_cgroup
> >>*memc
On Thu 09-08-12 17:01:10, Glauber Costa wrote:
[...]
> For now retry up to COSTLY_ORDER (as page_alloc.c does) and make sure
> not to do it if __GFP_NORETRY.
Who is using __GFP_NORETRY for user backed memory (except for hugetlb
which has its own controller)?
--
Michal Hocko
SUSE Labs
On Fri 10-08-12 19:30:00, Michal Hocko wrote:
> On Thu 09-08-12 17:01:10, Glauber Costa wrote:
> [...]
> > For now retry up to COSTLY_ORDER (as page_alloc.c does) and make sure
> > not to do it if __GFP_NORETRY.
>
> Who is using __GFP_NORETRY for user backed memory (except
wa Hiroyuki
I am not happy with the min_pages argument but we can do something more
clever later.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
&
On Sun 12-08-12 12:08:21, Hillf Danton wrote:
> On Fri, Aug 10, 2012 at 9:48 PM, Michal Hocko wrote:
>
> > It's been compile tested because it only restores the previous code with
> > a simple and obvious bug fix.
>
> It helps more if you elaborate on such a simple
On Mon 13-08-12 20:10:41, Hillf Danton wrote:
> On Sun, Aug 12, 2012 at 5:31 PM, Michal Hocko wrote:
> > From d07b88a70ee1dbcc96502c48cde878931e7deb38 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Fri, 10 Aug 2012 15:03:07 +0200
> > Subject:
On Mon 13-08-12 12:05:38, Glauber Costa wrote:
> On 08/10/2012 10:54 PM, Michal Hocko wrote:
> > On Thu 09-08-12 17:01:10, Glauber Costa wrote:
> >> From: Suleiman Souhlal
> >>
> >> mem_cgroup_do_charge() was written before kmem accounting, and expects
>
On Mon 13-08-12 21:24:36, Hillf Danton wrote:
> On Mon, Aug 13, 2012 at 9:09 PM, Michal Hocko wrote:
> > On Mon 13-08-12 20:10:41, Hillf Danton wrote:
> >> On Sun, Aug 12, 2012 at 5:31 PM, Michal Hocko wrote:
> >> > From d07b88a70ee1dbcc96502c48cde878931e7
vma_hugecache_offset is not incorrect because the pgoff will fit
into the same vmas but it is confusing so the standard PAGE_SHIFT based
index calculation is used instead.
Cc: Hillf Danton
Cc: Mel Gorman
Cc: KAMEZAWA Hiroyuki
Cc: Andrea Arcangeli
Cc: David Rientjes
Signed-off-by: Michal Hocko
PATCHES_START/#NEXT_PATCHES_END markers are included in
> linux-next.
>
> A git tree which contains the memory management portion of this tree is
> maintained at https://github.com/mstsxfx/memcg-devel.git by Michal Hocko.
> It contains the patches which are between the "#NEX
a must then this should be
documented here.
One nit bellow.
> 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-by: Glauber Costa
>
gt; Signed-off-by: Glauber Costa
> CC: Christoph Lameter
> CC: Pekka Enberg
> CC: Michal Hocko
> CC: Kamezawa Hiroyuki
> CC: Johannes Weiner
> ---
> include/linux/memcontrol.h | 79 +++
> mm/memcontrol.c| 185
> ++
ing.
I would go with struct mem_cgroup **memcgp or even return the pointer on
success or NULL otherwise.
[...]
> +EXPORT_SYMBOL(__free_accounted_pages);
Why exported?
Btw. this is called from call_rcu context but it itself calls call_rcu
down the chain in mem_cgroup_put. Is it safe?
[...]
>
e perfectly able to set a
> different limit than its parents. Note that this is not a boolean.
Ohh, I wasn't clear enough. I am not against setting the _limit_ I just
meant that the kmem_accounted should be consistent within the hierarchy.
--
Michal Hocko
SUSE Labs
--
To unsubscribe fro
?
> We do need to get this nailed down because it's the foundation of the
> patch series.
There is a slot in MM/memcg minisum at KS so we have a slot to discuss
this.
>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups&q
et accounted as well. This is
> not the state in this patch, but gets added later. Isn't this enough ?
But if the parent is not accounted, you can set the children to be
accounted, right? Or maybe this is changed later in the series? I didn't
get to the end yet.
--
Michal Hocko
be disastrous.
It's not just about shrink_slab it is also about triggering memcg-oom
which doesn't consider kmem accounted memory so the wrong tasks could
be killed. It is true that the impact is packed inside the group
(hierarchy) so you are right it won't be disastrous.
--
Michal Ho
On Wed 15-08-12 17:04:31, Glauber Costa wrote:
> On 08/15/2012 05:02 PM, Michal Hocko wrote:
> > On Wed 15-08-12 16:53:40, Glauber Costa wrote:
> > [...]
> >>>>> This doesn't check for the hierachy so kmem_accounted might not be in
> >>>>>
On Wed 15-08-12 17:31:24, Glauber Costa wrote:
> On 08/15/2012 05:26 PM, Michal Hocko wrote:
> > On Wed 15-08-12 17:04:31, Glauber Costa wrote:
> >> On 08/15/2012 05:02 PM, Michal Hocko wrote:
> >>> On Wed 15-08-12 16:53:40, Glauber Costa wrote:
> >>>
On Wed 15-08-12 18:01:51, Glauber Costa wrote:
> On 08/15/2012 05:09 PM, Michal Hocko wrote:
> > On Wed 15-08-12 13:42:24, Glauber Costa wrote:
> > [...]
> >>>> +
> >>>> +ret = 0;
> >>>> +
> >>>> +if (
ught we are not doing atomic allocations in user pages accounting
but I was obviously wrong because at least shmem uses atomic
allocations for ages.
> Do you have any other concerns specific to this patch ?
I understood you changed also handle thingy. So the patch should be
correct.
Do you plan
On Thu 16-08-12 13:57:07, Glauber Costa wrote:
> On 08/16/2012 01:53 PM, Michal Hocko wrote:
> > On Wed 15-08-12 18:27:45, Glauber Costa wrote:
> >>
> >>>>
> >>>> I see now, you seem to be right.
> >>>
> >>> No I am not becaus
On Thu 16-08-12 20:45:15, Hillf Danton wrote:
> On Mon, Aug 13, 2012 at 9:55 PM, Michal Hocko wrote:
> > 0c176d5 (mm: hugetlb: fix pgoff computation when unmapping page
> > from vma) fixed pgoff calculation but it has replaced it by
> > vma_hugecache_offset which is not app
On Wed 15-08-12 12:50:55, Ying Han wrote:
> On Tue, Aug 14, 2012 at 9:21 AM, Michal Hocko wrote:
> > On Thu 09-08-12 17:01:12, Glauber Costa wrote:
> >> This patch adds the basic infrastructure for the accounting of the slab
> >> caches. To control that, the
On Thu 16-08-12 17:09:54, Will Deacon wrote:
> On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
> > I guess the cleanest way is to hook into dequeue_huge_page_node and add
> > something like arch_clear_hugepage_flags.
>
> I hooked into enqueue_huge_page i
On Thu 16-08-12 18:34:59, Will Deacon wrote:
> On Thu, Aug 16, 2012 at 06:25:27PM +0100, Michal Hocko wrote:
> > On Thu 16-08-12 17:09:54, Will Deacon wrote:
> > > On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
> > > > I guess the cleanest way is to ho
On Thu 16-08-12 17:09:54, Will Deacon wrote:
> On Wed, Aug 08, 2012 at 05:26:07PM +0100, Michal Hocko wrote:
[...]
> diff --git a/arch/ia64/include/asm/hugetlb.h b/arch/ia64/include/asm/hugetlb.h
> index da55c63..2adaa60 100644
> --- a/arch/ia64/include/asm/hugetlb.h
> +++ b/arch/i
xt.
>
> A git tree which contains the memory management portion of this tree is
> maintained at https://github.com/mstsxfx/memcg-devel.git by Michal Hocko.
> It contains the patches which are between the "#NEXT_PATCHES_START mm" and
> "#NEXT_PATCHES_END" markers,
On Mon 23-07-12 18:08:05, Hugh Dickins wrote:
> On Mon, 23 Jul 2012, Mel Gorman wrote:
> > On Sun, Jul 22, 2012 at 09:04:33PM -0700, Hugh Dickins wrote:
> > > On Fri, 20 Jul 2012, Mel Gorman wrote:
> > > > On Fri, Jul 20, 2012 at 04:36:35PM +0200, Michal Hocko wro
ooked like it was
> going to deadlock on i_mmap_mutex (with or without my patch) but does
> not as hugetlbfs has its own hugetlbfs_setattr() and hugetlb_vmtruncate()
> which don't use unmap_mapping_range() at all.
>
> invalidate_inode_pages2() (and _range()) do use unmap_mapping
es are applied.
>
> Jump label decrement happens when the last reference count from the
> memcg dies. This will only happen when the caches are all dead.
>
> Signed-off-by: Glauber Costa
> Acked-by: Kamezawa Hiroyuki
> CC: Christoph Lameter
> CC: Pekka Enberg
> CC: M
On Fri 17-08-12 11:01:06, Glauber Costa wrote:
> On 08/17/2012 11:02 AM, Michal Hocko wrote:
> > On Thu 09-08-12 17:01:16, Glauber Costa wrote:
> >> We can use jump labels to patch the code in or out when not used.
> >>
> >> Because the assignment: memcg->
verse operation when a formerly limited cgroup becomes
> unlimited.
>
> Signed-off-by: Glauber Costa
> CC: Christoph Lameter
> CC: Pekka Enberg
> CC: Michal Hocko
> CC: Kamezawa Hiroyuki
> CC: Johannes Weiner
> CC: Suleiman Souhlal
> ---
> mm/memcontrol.c | 88
On Fri 17-08-12 13:15:47, Glauber Costa wrote:
> On 08/17/2012 01:00 PM, Michal Hocko wrote:
> > On Thu 09-08-12 17:01:17, Glauber Costa wrote:
> >> The current memcg slab cache management fails to present satisfatory
> >> hierarchical behavior in the following scen
On Fri 17-08-12 14:07:00, Glauber Costa wrote:
> On 08/17/2012 01:35 PM, Michal Hocko wrote:
> >>> Above you said "Once enabled, can't be disabled." and now you can
> >>> > > disable it? Say you are a leaf group with non accounted parents. This
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 commen
n they could be fixed by checking
the kmem limit as well.
> Signed-off-by: Glauber Costa
> Acked-by: Kamezawa Hiroyuki
> CC: Christoph Lameter
> CC: Pekka Enberg
> CC: Michal Hocko
> CC: Johannes Weiner
> CC: Suleiman Souhlal
> ---
> mm/memcontrol.c | 17 +
On Tue 21-08-12 09:54:30, Michal Hocko wrote:
> E.g. how do you handle charges you left behind? Say you charged some
> pages for stack?
I got to the last patch and see how you do it. You are relying on
free_accounted_pages directly which doesn't check kmem_accounted and
uses PageUsed
om
but that one will usually pick up something else than the fork bomb
which would have a small memory footprint. But that needs to be handled
on the oom level obviously.
> Signed-off-by: Glauber Costa
> Acked-by: Frederic Weisbecker
> CC: Christoph Lameter
> CC: Pekka Enberg
&g
On Tue 21-08-12 13:22:09, Glauber Costa wrote:
> On 08/21/2012 11:54 AM, Michal Hocko wrote:
[...]
> > But maybe you have a good use case for that?
> >
> Honestly, I don't. For my particular use case, this would be always on,
> and end of story. I was operating under the
On Tue 21-08-12 13:40:45, Glauber Costa wrote:
> On 08/21/2012 01:35 PM, Michal Hocko wrote:
[...]
> > I am asking because this should trigger memcg-oom
> > but that one will usually pick up something else than the fork bomb
> > which would have a small memory footprint.
crepancy,
please?
> Reported-by: David Rientjes
> Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
[...]
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 8137aea..aa06bf4 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
[...]
> @@ -1519,10 +1512,9 @@ migrate_misplac
at swapoff", the condition is always true when this
> code is reached.
>
> Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/swapfile.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> in
from:
shmem_unuse
mem_cgroup_cache_charge
shmem_unuse_inode
shmem_add_to_page_cache
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
;
> Signed-off-by: Johannes Weiner
with the fix later in the thread
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 18 --
> 1 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 4ea19c6..a3bf414 10
re to be not in swapcache.
>
> Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 13 -
> 1 files changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index a3bf414..3d56b4e 10
On Thu 05-07-12 02:44:58, Johannes Weiner wrote:
> Charging cache pages may require swapin in the shmem case. Save the
> forward declaration and just move the swapin functions above the cache
> charging functions.
>
> Signed-off-by: Johannes Weiner
OK
Acked-by: Michal Hock
e confusing.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 11 +--
> 1 files changed, 1 insertions(+), 10 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 4a41b55..418b47d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
&g
On Thu 05-07-12 02:45:00, Johannes Weiner wrote:
> It does not matter to __mem_cgroup_try_charge() if the passed mm is
> NULL or init_mm, it will charge the root memcg in either case.
>
> Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c |
t shmem use the
> internal version directly and allow future patches to move around
> checks that are only required when swapping in anon pages.
>
> Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 24 +++-
> 1 files ch
p cache is also serialized by the page lock,
> and since both the try_charge and commit_charge are called under the
> same page lock section, the PageCgroupUsed() check might as well
> happen before the counter charging, let alone reclaim.
>
> Signed-off-by: Johannes Weiner
Acked-
Signed-off-by: Johannes Weiner
Looks good
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 22 ++
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index d3701cd..9b7e256 100644
> --- a/m
| 27 ++-
> mm/shmem.c | 11 ++-
> mm/swapfile.c |3 +-
> 5 files changed, 124 insertions(+), 133 deletions(-)
>
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
To unsubscribe from this list: send the
On Tue 10-07-12 14:10:21, Wanpeng Li wrote:
> On Mon, Jul 09, 2012 at 05:20:58PM +0200, Michal Hocko wrote:
> >On Thu 05-07-12 02:45:00, Johannes Weiner wrote:
> >> It does not matter to __mem_cgroup_try_charge() if the passed mm is
> >> NULL or init_mm, it will char
901 - 1000 of 11648 matches
Mail list logo
