On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> > On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > > On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 1
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> > > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 1
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
> Wait a moment. But what prevents from the following race?
>
> rcu_read_lock()
cgroup_next_descendant_pre
css_tryget(css);
memcg = mem_cgroup_from_css(css)atomic_add(CSS_DEACT_BIAS,
&am
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> [...]
> The example was not complete:
>
> > Wait a moment. But what prevents from the following race?
> >
> > rcu_read_lock()
>
> cgroup_next_desce
On Tue 12-02-13 17:24:42, Michal Hocko wrote:
> On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> > On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> > [...]
> > The example was not complete:
> >
> > > Wait a moment. But what prevents from the follow
On Tue 12-02-13 11:41:03, Johannes Weiner wrote:
>
>
> Michal Hocko wrote:
>
> >On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> >> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> >> [...]
> >> The example was not complete:
> >>
> >
/proc/kcore so the patch has
> not been validated but I think it makes sense. If reviewers agree then it
> should also be included in -stable back as far as 3.0-stable.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Mel Gorman
Reviewed-by: Michal Hocko
> ---
> arch/x86/include/as
On Tue 12-02-13 08:10:51, Paul E. McKenney wrote:
> On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> > On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> > > On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 1
On Mon 01-04-13 13:14:50, Ilija Hadzic wrote:
>
>
> On Sun, 31 Mar 2013, Michal Hocko wrote:
>
> >On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> >>This looks a bit like a hack and it doesn't look right,
> >>conceptually. If the call fails, it should
Tejun,
could you take this one please?
On Thu 28-03-13 08:48:14, Michal Hocko wrote:
> On Wed 27-03-13 18:32:23, Michal Hocko wrote:
> [...]
> > Removed WARN_ON_ONCE as suggested by Johannes and kept kmalloc with
> > PATH_MAX used instead of PAGE_SIZE. I've kept Glauber&#
On Fri 29-03-13 13:23:38, Naoya Horiguchi wrote:
> Hi,
>
> On Fri, Mar 29, 2013 at 02:57:30PM +0100, Michal Hocko wrote:
> > On Thu 28-03-13 11:42:38, Naoya Horiguchi wrote:
> > [...]
> > > @@ -2968,7 +2968,8 @@ long follow_hugetlb_page(struct mm_struct *mm,
&g
On Mon 01-04-13 10:43:14, Aneesh Kumar K.V wrote:
> Michal Hocko writes:
>
> > 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 v3.9-rc3/mm/memory-failure
goto err_destroy
err_destroy:
cgroup_destroy_locked(cgrp)
offline_css
mem_cgroup_css_offline
no mem_cgroup_put on the way.
--
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
Mo
On Tue 02-04-13 16:22:23, Glauber Costa wrote:
> On 04/02/2013 04:16 PM, Michal Hocko wrote:
> > On Tue 02-04-13 15:35:28, Li Zefan wrote:
> > [...]
> >> @@ -6247,16 +6247,7 @@ mem_cgroup_css_online(struct cgroup *cont)
> >>
> >>error =
On Tue 02-04-13 14:16:00, Michal Hocko wrote:
> On Tue 02-04-13 15:35:28, Li Zefan wrote:
> [...]
> > @@ -6247,16 +6247,7 @@ mem_cgroup_css_online(struct cgroup *cont)
> >
> > error = memcg_init_kmem(memcg, &mem_cgroup_subsys);
> > mutex_unlock(&
On Tue 02-04-13 18:20:56, Glauber Costa wrote:
> On 04/02/2013 06:16 PM, Michal Hocko wrote:
> > mem_cgroup_css_online
> > memcg_init_kmem
> > mem_cgroup_get # refcnt = 2
> > memcg_update_all_caches
> > memcg_upda
On Tue 02-04-13 18:33:30, Glauber Costa wrote:
> On 04/02/2013 06:28 PM, Michal Hocko wrote:
> > On Tue 02-04-13 18:20:56, Glauber Costa wrote:
> >> On 04/02/2013 06:16 PM, Michal Hocko wrote:
> >>> mem_cgroup_css_online
> >>> memcg_init_kmem
> &
only implementation
> > of init_cgroup seems to be tcp_init_cgroup which doesn't fail
> > but it is better to make the error handling saner and move the
> > mem_cgroup_put(memcg) to memcg_propagate_kmem where it belongs.
> >
> > Signed-off-by: Li Zefan
> > Signed-off-b
On Wed 03-04-13 15:49:06, Li Zefan wrote:
> On 2013/4/3 15:43, Michal Hocko wrote:
> > On Wed 03-04-13 11:49:29, Li Zefan wrote:
> >>>> Yes, indeed you are very right - and thanks for looking at such depth.
> >>>
> >>> So what about the patc
similar to your patch. So feel free to add my Acked-by and parts of my
changelog that fit (namely obvious bug introduced by e4715f01 and
documentnation of the clean-up path). I have a split up version in case
others like it more - will follow.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscri
: Michal Hocko
---
mm/memcontrol.c |2 --
1 file changed, 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f608546..6de6d70 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6424,8 +6424,6 @@ mem_cgroup_css_online(struct cgroup *cont)
* call
rely on kmem_cgroup_destroy doing the right
thing.
Signed-off-by: Li Zefan
Signed-off-by: Michal Hocko
---
mm/memcontrol.c |8
1 file changed, 8 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6de6d70..65b2850 100644
--- a/mm/memcontrol.c
+++ b/mm/memcont
On Wed 03-04-13 10:53:54, Michal Hocko wrote:
> mem_cgroup_css_online calls mem_cgroup_put if memcg_init_kmem
> fails. This is not correct because only memcg_propagate_kmem takes an
> additional reference while mem_cgroup_sockets_init is allowed to fail as
> well (althoug
return kmalloc(size, GFP_NOWAIT);
> again:
>
> /* do not panic in alloc_bootmem_bdata() */
You need to update alloc_bootmem_bdata and alloc_bootmem_core as well.
Otherwise this is a no-op for early allocations when slab is not
available which is the case unless
&node_states[N_MEMORY])),
> huge_page_size(h), huge_page_size(h), 0);
Ohh, and powerpc seems to have its own opinion how to allocate huge
pages. See arch/powerpc/mm/hugetlbpage.c
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe
}
>
> What happens if this tryget fails ? Won't we leak a reference here? We
> will put regardless when the socket is released, and this may go
> negative. No?
AFAICS sock_release_memcg releases the reference only if sk->sk_cgrp and
that one wouldn't be set if css_tryget fails.
--
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/
g_params->memcg_caches[idx] = new_cachep;
> @@ -3449,8 +3451,6 @@ static void memcg_create_cache_work_func(struct
> work_struct *w)
>
> cw = container_of(w, struct create_work, work);
> memcg_create_kmem_cache(cw->memcg, cw->cachep);
> - /* Drop the reference go
n have lost VM_RESERVED check which used to stop hugetlb
mappings.
Acked-by: Michal Hocko
> ---
> fs/binfmt_elf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git v3.9-rc3.orig/fs/binfmt_elf.c v3.9-rc3/fs/binfmt_elf.c
> index 3939829..86af964 100644
> --- v3.9-rc3.ori
On Wed 03-04-13 14:33:34, Tejun Heo wrote:
> On Tue, Apr 02, 2013 at 10:26:48AM +0200, Michal Hocko wrote:
> > Tejun,
> > could you take this one please?
>
> Aye aye, applied to cgroup/for-3.10.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the li
On Wed 03-04-13 12:00:12, Robin Holt wrote:
> On Wed, Apr 03, 2013 at 04:02:47PM +0200, Michal Hocko wrote:
> > On Tue 02-04-13 21:43:44, Robin Holt wrote:
> > [...]
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index ca9a7c6..7683f6a 100644
> > > -
On Wed 03-04-13 12:21:32, Robin Holt wrote:
> On Wed, Apr 03, 2013 at 04:00:49PM +0200, Michal Hocko wrote:
> > On Tue 02-04-13 21:43:44, Robin Holt wrote:
> > [...]
> > > diff --git a/mm/bootmem.c b/mm/bootmem.c
> > > index 2b0bcb0..b2e4027 100644
> > > -
struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
>
> + kmem_cgroup_css_offline(memcg);
> +
> mem_cgroup_invalidate_reclaim_iterators(memcg);
> mem_cgroup_reparent_charges(memcg);
> mem_cgroup_destroy_all_caches(memcg);
> @@ -6283,7 +6286,7 @@ static v
On Wed 03-04-13 17:12:54, Li Zefan wrote:
> Use css_get/put instead of mem_cgroup_get/put.
>
> Signed-off-by: Li Zefan
Looks good to me. Swapped in pages still use css_tryget so they would
fallback to recharge in __mem_cgroup_try_charge_swapin if the group was
removed.
Acked-by: Mic
> @@ -4171,6 +4178,9 @@ static long cgroup_create(struct cgroup *parent, struct
> dentry *dentry,
> for_each_subsys(root, ss)
> dget(dentry);
>
> + /* hold a ref to the parent's dentry */
> + dget(parent->dentry);
> +
> /* cr
safe with the workqueue based releasing as
well once mem_cgroup_{get,put} are gone, right?
> Note this patchset is based on a few memcg fixes I sent (but hasn't been
> accepted)
>
> --
> kernel/cgroup.c | 10
> mm/memcontrol.c | 129
> ++++++++
On Thu 04-04-13 06:53:53, Tejun Heo wrote:
> Hey,
>
> On Thu, Apr 04, 2013 at 01:37:50PM +0200, Michal Hocko wrote:
> > On Wed 03-04-13 17:13:08, Li Zefan wrote:
> > > Suppose we rmdir a cgroup and there're still css refs, this cgroup won't
> > > be free
On Thu 04-04-13 08:22:13, Tejun Heo wrote:
> On Thu, Apr 04, 2013 at 05:20:28PM +0200, Michal Hocko wrote:
> > > But what harm does an additional reference do?
> >
> > No harm at all. I just wanted to be sure that this is not yet another
> > "for memcg&qu
s to access its parent.
>
> Make sure this won't happen.
>
> Signed-off-by: Li Zefan
OK, after clarification from Tejun, that this is helpful for other
controllers as well I think it is better than a memcg specific handling.
Reviewed-by: Michal Hocko
> ---
> kernel/c
low.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ad576e8..45129cd 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6124
On Wed 03-04-13 17:14:11, Li Zefan wrote:
> Now memcg has the same life cycle as the corresponding cgroup.
> Kill the useless refcnt.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Thanks!
> ---
> mm/memcontrol.c | 24 +---
> 1 file change
age_alloc.c |2 +-
> 6 files changed, 82 insertions(+), 29 deletions(-)
>
> --
> 1.7.10.4
>
> --
> 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 Thu 04-04-13 18:17:46, Michal Hocko wrote:
> On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> > order >= MAX_ORDER pages are only allocated at boot stage using the
> > bootmem allocator with the "hugepages=xxx" option. These pages are never
> > free after boot
On Fri 05-04-13 09:14:58, Simon Jeons wrote:
> Hi Michal,
> On 03/22/2013 04:15 PM, Michal Hocko wrote:
> >[getting off-list]
> >
> >On Fri 22-03-13 07:46:32, Simon Jeons wrote:
> >>Hi Michal,
> >>On 03/21/2013 08:56 PM, Michal Hocko wrote:
> &
On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> >> order >= MAX_ORDER pages are only allocated at boot stage using the
> >> bootmem allocator with the "
On Fri 05-04-13 16:27:59, Wanpeng Li wrote:
> On Fri, Apr 05, 2013 at 10:12:39AM +0200, Michal Hocko wrote:
> >On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> >> On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >> >On Thu 04-04-13 17:09:08, Wanpeng Li wro
On Fri 05-04-13 17:00:58, Simon Jeons wrote:
> Hi Michal,
> On 04/05/2013 04:08 PM, Michal Hocko wrote:
> >On Fri 05-04-13 09:14:58, Simon Jeons wrote:
> >>Hi Michal,
> >>On 03/22/2013 04:15 PM, Michal Hocko wrote:
> >>>[getting off-list]
> >>
On Fri 05-04-13 16:54:44, Simon Jeons wrote:
> Hi Michal,
> On 04/05/2013 04:12 PM, Michal Hocko wrote:
> >On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> >>On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >>>On Thu 04-04-13 17:09:08, Wanpeng Li wrot
On Fri 05-04-13 12:08:40, Glauber Costa wrote:
> On 04/03/2013 07:29 PM, Michal Hocko wrote:
> > On Wed 03-04-13 16:58:48, Glauber Costa wrote:
> >> On 04/03/2013 01:11 PM, Li Zefan wrote:
> >>> Use css_get/css_put instead of mem_cgroup_get/put.
> >>>
zed.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 23d0f6e..43ca91d 100644
> --- a/mm/memcontrol.c
&g
On Fri 05-04-13 14:28:12, Glauber Costa wrote:
> On 04/03/2013 07:31 PM, Michal Hocko wrote:
> > On Wed 03-04-13 17:12:21, Li Zefan wrote:
> >> Use css_get()/css_put() instead of mem_cgroup_get()/mem_cgroup_put().
> >>
> >> Signed-off-by: Li Zefan
gt; + css_put(&memcg->css);
> > goto out;
> > + }
>
> Where css_get() against this is done ?
As glauber explained in another email in this thread. It was
__memcg_create_cache_enqueue which took the reference.
--
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/
em_test_and_clear_dead which imply a full memory barrier but it
> > should see the elevated reference count. No?
> >
>
> We don't use barriers for any other kind of reference counting. What is
> different here?
Now we need to make sure that the racing uncharge sees an elevated
reference count before the group is marked dead. Otherwise we could see
a dead group with ref count == 0, no?
--
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/
tingush why mbind was failed.
Sure, and I wasn't suggesting to change alloc_huge_page. I was just
pointing out that new_page_t used to return page or NULL and hugetlb
unmap_and_move shouldn't be any different in that direction so using
alloc_huge_page is not a good fit here.
> Anyway, If
laim >= sc->nr_reclaimed) {
+ sc->nr_to_reclaim <= sc->nr_reclaimed) {
mem_cgroup_iter_break(root, memcg);
break;
}
--
1.7.10.4
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list:
On Wed 30-01-13 11:22:57, Johannes Weiner wrote:
> On Tue, Jan 29, 2013 at 09:51:04AM +0100, Michal Hocko wrote:
> > Ying has noticed me (via private email) that the patch is bogus because
> > the break out condition is incorrect. She said she would post a fix
> > but she
> get_lru_size() does the right thing for both global and memcg reclaim
> situations.
>
> Get rid of inactive_file_is_low_global() and
> mem_cgroup_inactive_file_is_low() by using get_lru_size() and compare
> the numbers in common code.
>
> Signed-off-by: Johannes Weiner
ored into a git tree.
http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
It contains only Memory management patches on top of the last major
release (since-.X.Y branch).
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linu
On Fri 25-01-13 16:07:23, azurIt wrote:
> Any news? Thnx!
Sorry, but I didn't get to this one yet.
>
> azur
>
>
>
> ______
> > Od: "Michal Hocko"
> > Komu: azurIt
> > Dátum: 30.1
Gleixner
Cc: "H. Peter Anvin"
Cc: Len Brown
Cc: "Brown, Len"
Signed-off-by: Michal Hocko
---
include/linux/acpi.h |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b29e0aa..4c66ac0 100644
--- a/
On Mon 28-01-13 09:33:49, Tang Chen wrote:
> On 01/25/2013 09:17 PM, Michal Hocko wrote:
> >On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> >>On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> >>>Here are some bug fix patches for physical memory hot-remove. All t
m parent hitting its
limit?
> +
> for_each_evictable_lru(lru) {
> int file = is_file_lru(lru);
> unsigned long size;
> @@ -1786,6 +1790,7 @@ out:
>
> size = get_lru_size(lruvec, lru);
> scan = size >>
emory to count page types is very expensive and should
> + * be inhibited in non-blockable contexts.
> + */
> + if (!(gfp_mask & __GFP_WAIT))
> + filter |= SHOW_MEM_FILTER_PAGE_COUNT;
> +
> + /*
>* This documents exceptions given to a
On Wed 27-02-13 14:39:36, Roman Gushchin wrote:
> 27.02.2013, 13:41, "Michal Hocko" :
> > Let me restate what I have already mentioned in the private
> > communication.
> >
> > We already have soft limit which can be implemented to achieve the
> > same/
On Thu 28-02-13 15:13:15, Roman Gushchin wrote:
> 27.02.2013, 20:14, "Michal Hocko" :
> > On Wed 27-02-13 14:39:36, Roman Gushchin wrote:
[...]
> >> 2) cgroup's prioritization during global reclaim,
> >
> > Yes, group priorities sound like a useful
t get scanned when under/close_to
limit while big groups do get scanned and reclaimed.
> I don't like an idea to start ignoring low limit on some priorities.
Well, but you are doing that already. If you are reclaiming for prio 0 then
you add up just DEF_PRIORITY-2 which means you reclaim for a
ge struct field helpers
mm/fadvise.c: drain all pagevecs if POSIX_FADV_DONTNEED fails to discard
all pages
Michal Hocko (9):
memcg,vmscan: do not break out targeted reclaim without reclaimed pages
memory-hotplug: cleanup: removing the arch specific functions without any
implemen
u point me to the two patches you
have applied in the mean 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.ht
sk/lkml/patches2
OK, looks correct.
--
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/
[Let's CC Ingo and Peter]
On Tue 12-03-13 11:15:55, Michal Hocko wrote:
> On Tue 12-03-13 14:36:46, Li Zefan wrote:
> > Seems a new bug in 3.9 kernel?
> >
> >
> > [ 207.271924] ==
> > [ 207.271
[CCing Greg and Kay]
On Tue 12-03-13 12:07:50, Michal Hocko wrote:
> [Let's CC Ingo and Peter]
>
> On Tue 12-03-13 11:15:55, Michal Hocko wrote:
> > On Tue 12-03-13 14:36:46, Li Zefan wrote:
> > > Seems a new bug in 3.9 kernel?
>
On Tue 12-03-13 16:28:25, Peter Zijlstra wrote:
> On Tue, 2013-03-12 at 14:05 +0100, Michal Hocko wrote:
> > @@ -111,17 +111,17 @@ struct bus_type {
> > struct iommu_ops *iommu_ops;
> >
> > struct subsys_private *p;
> > + struct lock_class_
On Tue 12-03-13 06:34:46, Greg Kroah-Hartman wrote:
> On Tue, Mar 12, 2013 at 02:05:04PM +0100, Michal Hocko wrote:
> > The fix is quite simple. We can pull the key inside bus_type structure
> > because they are defined per device so the pointer will be unique as
> > well.
Hi,
On Thu 07-03-13 15:46:19, 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
> "#N
Hi Andrew,
it seems that there were no other objections[1] to this version of the
patchset. Could you take it into your tree and target it for 3.10?
---
[1] The only one from Johannes (https://lkml.org/lkml/2013/2/8/379) has
been addressed
On Thu 14-02-13 14:26:30, Michal Hocko wrote:
>
2.7 Kernel Memory Extension
(CONFIG_MEMCG_KMEM)" for more information)
--
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/
m/bootmem.c | 12 +++-
> mm/hugetlb.c |3 ++-
> mm/nobootmem.c | 41
> +++--
> mm/page_cgroup.c | 2 +-
> mm/sparse.c|2 +-
> 7 fi
; --
> 1.7.11.7
>
> --
> 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
--
M
ht
contain a lot of patches on top of the core kernel. I would suggest to
contact Redhat or try to reproduce the issue with the vanilla and
up-to-date kernel and report here.
--
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/
e(h);
> + return nr_total_pages;
> }
>
> static int hugetlb_acct_memory(struct hstate *h, long delta)
> --
> 1.7.11.7
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM
On Thu 14-03-13 19:24:11, Wanpeng Li wrote:
> On Thu, Mar 14, 2013 at 12:09:27PM +0100, Michal Hocko wrote:
> >On Thu 14-03-13 18:49:49, Wanpeng Li wrote:
> >> Changelog:
> >> v1 -> v2:
> >> * update patch description, spotted by Michal
> >>
>
: hugepagesz=1G hugepages=1
> the default overcommit ratio is 50
> before patch:
> egrep 'CommitLimit' /proc/meminfo
> CommitLimit: 55434168 kB
> after patch:
> egrep 'CommitLimit' /proc/meminfo
> CommitLimit: 54909880 kB
>
Is this information useful
same for all archs except
for some. Can we just make one common definition and define only those
that differ, please?
[...]
--
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 Thu 14-03-13 15:11:09, Gerald Schaefer wrote:
> On Thu, 14 Mar 2013 14:14:04 +0100
> Michal Hocko wrote:
>
> > On Tue 12-03-13 19:48:26, Gerald Schaefer wrote:
> > > Commit abf09bed3c "s390/mm: implement software dirty bits" introduced
> > > anoth
t; This change will be a no-op for those architectures.
>
> Signed-off-by: Gerald Schaefer
yes this looks much better. I cannot talk about s390 part because I am
not familiar with it but the rest looks good to me.
Maybe one nit, though. pte_page and pte_same do not have their huge_Foo
counterpart
->use_hierarchy = true;
> +#endif
> } else {
> parent = mem_cgroup_from_cont(cont->parent);
> memcg->use_hierarchy = parent->use_hierarchy;
> --
> 1.7.11.4
>
> --
> To unsubscribe, send a message with 'unsubscribe lin
On Tue 04-09-12 12:34:45, Glauber Costa wrote:
> On 09/03/2012 09:08 PM, Michal Hocko wrote:
> > On Mon 03-09-12 19:46:51, Glauber Costa wrote:
> >> Here is a new attempt to lay down a path that will allow us to deprecate
> >> the non-hierarchical mode of operation
On Tue 04-09-12 17:27:20, Glauber Costa wrote:
> On 09/04/2012 05:09 PM, Michal Hocko wrote:
> > Not really. Do it slowly means that somebody actually _notices_ that
> > something is about to change and they have a lot of time for that. This
> > will be really hard with the c
On Tue 04-09-12 18:37:53, Glauber Costa wrote:
> On 09/04/2012 06:35 PM, Michal Hocko wrote:
> > On Tue 04-09-12 17:27:20, Glauber Costa wrote:
> >> On 09/04/2012 05:09 PM, Michal Hocko wrote:
> >>> Not really. Do it slowly means that somebody actually _notices_ th
ocation to unpatch in case/when it
> really goes away.
I guess that by the single location you mean that no other user space
changes would have to be done, right? If yes then this is not true
because there will be a lot of configurations setting this up already
(either by cgconfig or by other sc
. Remove the artificially low PRIOIDX_SZ
> + * limit and properly nest configuration such that children follow
> + * their parents' configurations by default and are allowed to
> + * override and remove the following.
> + */
> + .broken_hierarchy = trye,
ty
mm/huge_memory.c
>
> Steve Capper (1):
> mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE
>
> arch/x86/Kconfig |4
> include/asm-generic/pgtable.h |2 +-
> mm/Kconfig|2 +-
> mm/huge_memory.c |6 +++---
> 4 fi
defines this and it uses pmd_update.
>
> Cc: Arnd Bergmann
> Signed-off-by: Catalin Marinas
> Signed-off-by: Steve Capper
> Signed-off-by: Will Deacon
Other than that it looks good.
Reviewed-by: Michal Hocko
> ---
> include/asm-generic/pgtable.h |2 +-
> 1 fi
and set in each architecture's
> Kconfig file (at the moment x86, with ARM being set in a future patch).
>
> Signed-off-by: Steve Capper
> Signed-off-by: Will Deacon
Makes sense if there are going to be more archs to support THP.
Reviewed-by: Michal Hocko
> ---
> arch
collapse_huge_page(struct mm_struct *mm,
> BUG_ON(!pmd_none(*pmd));
> page_add_new_anon_rmap(new_page, vma, address);
> set_pmd_at(mm, address, pmd, _pmd);
> - update_mmu_cache(vma, address, _pmd);
> + update_mmu_cache(vma, address, pmd);
>
On Tue 11-09-12 10:07:46, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Sep 11, 2012 at 12:04:33PM +0200, Michal Hocko wrote:
> > > cgroup_unlock();
> > > @@ -4953,6 +4958,7 @@ mem_cgroup_create(struct cgroup *cont)
> > >
On Wed 12-09-12 13:31:55, Glauber Costa wrote:
> On 09/11/2012 02:04 PM, Michal Hocko wrote:
> > I like the approach in general but see the comments bellow:
> >
> > On Mon 10-09-12 15:33:55, Tejun Heo wrote:
> > [...]
> >> --- a/mm/memcontrol.c
> >> ++
On Wed 12-09-12 10:11:20, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 12, 2012 at 05:49:07PM +0200, Michal Hocko wrote:
> > > While I respect your goal of not warning about any configuration
> > > with max_level = 1, I believe the only sane configuration as soon
> >
On Wed 12-09-12 16:55:55, Will Deacon wrote:
> On Wed, Sep 12, 2012 at 04:27:59PM +0100, Michal Hocko wrote:
> > On Tue 11-09-12 17:47:13, Will Deacon wrote:
> > > A few changes are required to common hugetlb code before the ARM support
> > > can be merged. I posted the
On Thu 13-09-12 10:18:32, Tejun Heo wrote:
> Hello, Michal.
>
> On Thu, Sep 13, 2012 at 02:14:38PM +0200, Michal Hocko wrote:
> > I would like to see use_hierarchy go away. The only concern I have is
> > to warn only if somebody is doing something wrong (aka flat
> >
am normally not that happy about pure typo fixes but as this is a
documentation they make sense here.
Acked-by: Michal Hocko
Andrew, could you take the patch, please? The original patch is here:
https://lkml.org/lkml/2012/9/11/167
Thanks!
> diff --git a/Documentation/cgroups/memory.txt
>
101 - 200 of 11645 matches
Mail list logo
