teach mem_cgroup_soft_reclaim_eligible
to handle NULL memcg as mem_cgroup_root
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 6 +-
mm/vmscan.c | 4 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c1be265..8629ca6 100644
--- a/mm/memcontrol.c
+++
roup_soft_reclaim_eligible
Signed-off-by: Michal Hocko
Reviewed-by: Glauber Costa
Reviewed-by: Tejun Heo
---
include/linux/memcontrol.h | 6 --
mm/memcontrol.c| 14 +-
mm/vmscan.c| 4 ++--
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/in
well. System time is around 100%
(suprisingly better for the 8k case) and Elapsed is copies that trend.
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
Now that the soft limit is integrated to the reclaim directly the whole
soft-limit tree infrastructure is not needed anymore. Rip it out.
Changes v1->v2
- mem_cgroup_reclaimable is no longer used
- test_mem_cgroup_node_reclaimable is not used outside NUMA code
Signed-off-by: Michal Ho
== root)
> > @@ -998,7 +998,7 @@ skip_node:
> > if (css_tryget(&mem->css))
> > return mem;
> > else {
> > - prev_cgroup = next_cgroup;
> > + prev_css =
ebug allocation failures?
> To fix this, suppress the page walk in such contexts when printing the
> page allocation failure warning.
>
> Signed-off-by: David Rientjes
> Cc: Mel Gorman
> Cc: Michal Hocko
> Cc: Dave Hansen
> Signed-off-by: Andrew Morton
> ---
>
>
On Fri 01-03-13 02:15:04, David Rientjes wrote:
> On Fri, 1 Mar 2013, Michal Hocko wrote:
>
> > I have already asked about it in the original thread but didn't get any
> > answer. How can we get a soft lockup when all implementations of show_mem
> > call touch_nmi_wat
s to 0-limit rework:
Base
Major min:208.00 max:454.00, avg:375.17 stdev:86.73
Rework
Major min:270.00 max:730.00, avg:431.67 stdev:143.58
So this clearly points at the priority-0 reclaim.
Shortlog says:
Michal Hocko (3):
memcg: integrate soft reclaim tighter with zone shrinking code
me
low up patch to make this patch smaller and easier to review.
Changes since v1
- __shrink_zone doesn't return the number of shrunk groups as nr_scanned
test covers both no groups scanned and no pages from the required zone
as pointed by Johannes
Signed-off-by: Michal Hocko
---
includ
Now that the soft limit is integrated to the reclaim directly the whole
soft-limit tree infrastructure is not needed anymore. Rip it out.
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 224 +--
1 file changed, 1 insertion(+), 223 deletions
roup_soft_reclaim_eligible
Signed-off-by: Michal Hocko
---
include/linux/memcontrol.h |6 --
mm/memcontrol.c| 14 +-
mm/vmscan.c|4 ++--
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/
age.
> */
> -int remove_mapping(struct address_space *mapping, struct page *page)
> +int remove_mapping(struct address_space *mapping, struct page *page,
> + bool irqcontext)
> {
> - if (__remove_mapping(mapping, page)) {
> + if (__remove_mapping(m
es properly]
> Signed-off-by: Mel Gorman
> Acked-by: Rik van Riel
active vs. inactive might get skewed a bit AFAICS because both of them
are zeroed but file vs. anon should be scanned proportionally based on
swappiness now which sounds like it is good enou
.
>
> Signed-off-by: Mel Gorman
> Acked-by: Johannes Weiner
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 86
> +
> 1 file changed, 41 insertions(+), 45 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmsca
ed the
> necessary pages are already available.
>
> Signed-off-by: Mel Gorman
> Acked-by: Johannes Weiner
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 59 ++-
> 1 file changed, 30 insertions(+), 29 deletions(-
he flag. Although direct
reclaim ignores the flag it still sets it without clearing it. This
means that you rely on parallel kswapd to clear it.
We do the same thing with ZONE_CONGESTED but I think this should be at
least documented somewhere.
Other than that
Reviewed-by: Michal Hocko
> ---
einer
Looks good
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 110
> +---
> 1 file changed, 54 insertions(+), 56 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index e65fe46..0ba9d3a 100644
> --- a/mm/
d 8b 38 49
> [ 115.097024] RIP [] kmem_cache_alloc+0x41/0x1f0
> [ 115.097024] RSP
> [ 115.097024] CR2: 000fffe0
> [ 115.121352] ---[ end trace 16bb8e8408b97d0e ]---
>
> Cc: Konstantin Khlebnikov
> Cc: Glauber Costa
> Cc: Johannes Weiner
> Cc: Michal
On Tue 14-05-13 16:40:31, Michal Hocko wrote:
> On Tue 14-05-13 16:38:38, Andrey Vagin wrote:
> > struct memcg_cache_params has a union. Different parts of this union are
> > used for root and non-root caches. A part with destroying work is used only
> > for non-
On Tue 14-05-13 18:49:07, Glauber Costa wrote:
> On 05/14/2013 06:44 PM, Michal Hocko wrote:
> > On Tue 14-05-13 16:40:31, Michal Hocko wrote:
> >> On Tue 14-05-13 16:38:38, Andrey Vagin wrote:
> >>> struct memcg_cache_params has a union. Different parts of this uni
4 53 48 83 ec 18 8b 05 8e 53 b7 00 4c 8b 4d 08 21 f0 a8
> 10 74 0d 4c 89 4d c0 e8 1b 76 4a 00 4c 8b 4d c0 e9 92 00 00 00 4d 89 f5 <4d>
> 8b 45 00 65 4c 03 04 25 48 cd 00 00 49 8b 50 08 4d 8b 38 49
> [ 115.097024] RIP [] kmem_cache_alloc+0x41/0x1f0
> [ 115.097024] RSP
> [
On Tue 14-05-13 22:09:34, Rafael J. Wysocki wrote:
> On Tuesday, May 14, 2013 06:01:08 PM Michal Hocko wrote:
> > Hi,
> > I am not able to make my system wake up from s2ram with 3.10-rc1. The
> > system simply starts booting as if it wasn't suspended. 3.9 wo
15/160)
For record:
$grep HYPERVISOR_GUEST .config
# CONFIG_HYPERVISOR_GUEST is not set
$grep PARAVIRT_GUEST .config
$
[...]
--
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 h
GUEST is not set
>
>
> Why not
> CONFIG_HYPERVISOR_GUEST=y
This is unrelated to the issue discussed in this thread.
--
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 16-05-13 11:33:45, Mel Gorman wrote:
[...]
> swapin in this case is an indication as to whether we are swap trashing.
> The closer the swapin/swapout ratio is to 0, the worse the
I guess you meant the ratio is closer to 1 not zero.
--
Michal Hocko
SUSE Labs
--
To unsubscrib
chset:
> - move memcg_dangling_add() to mem_cgroup_css_offline()
> - remove memcg->memcg_name, and use cgroup_path() in
> mem_cgroup_dangling_read()?
Every improvement is welcome.
Thanks
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Sun 07-04-13 14:00:24, Li Zefan wrote:
> On 2013/4/4 20:00, Michal Hocko wrote:
> > On Wed 03-04-13 17:11:15, Li Zefan wrote:
> >> (I'll be off from my office soon, and I won't be responsive in the
> >> following
> >> 3 days.)
> >>
>
- added wmb() in kmem_cgroup_css_offline(), pointed out by Michal
> - revised comments as suggested by Michal
> - fixed to check if kmem is activated in kmem_cgroup_css_offline()
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
Thanks!
> ---
> mm/memcontrol.c | 66
>
> This actually reverts 59927fb984de1703c67bc640c3e522d8b5276c73
> ("memcg: free mem_cgroup by RCU to fix oops").
>
> Cc: Hugh Dickins
> Signed-off-by: Li Zefan
OK, makes sense after the previous changes.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 51 +-
> @@ -5203,6 +5185,7 @@ static int mem_cgroup_dangling_read(struct cgroup
> *cont, struct cftype *cft,
> }
>
> mutex_unlock(&dangling_memcgs_mutex);
> + free_pages((unsigned long)memcg_name, 0);
> return 0;
> }
> #endif
> --
> 1.8.0.2
> --
> To
ns(-)
Nice and thanks a lot Li!
--
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/
ate *debug_css_alloc(struct cgroup *cont)
> {
> --
> 1.8.0.2
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 08-04-13 16:21:29, Li Zefan wrote:
> This is a preparation to kill css_id.
>
> Signed-off-by: Li Zefan
I would be tempted to stuff this into the same patch which introduces
cgroup_from_id but this is just a minor thing.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c |
guarantee for bisectability.
The patch on its own looks good.
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 3561d0b..c4e0173 100644
> --- a/mm/m
On Mon 08-04-13 16:22:34, Li Zefan wrote:
> memcg requires the cgroup id to be smaller than 65536.
>
> Signed-off-by: Li Zefan
But this should be moved up the patch stack as mentioned in the previous
email.
Acked-by: Michal Hocko
Minor nit bellow.
> ---
> mm/memcontrol.c | 9
On Mon 08-04-13 16:23:16, Li Zefan wrote:
> Now memcg uses cgroup->id instead of css_id. Update some comments and
> set mem_cgroup_subsys->use_id to 0.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 21 +++--
> 1 file c
On Mon 08-04-13 08:57:26, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 08, 2013 at 04:47:50PM +0200, Michal Hocko wrote:
> > On Mon 08-04-13 16:20:11, Li Zefan wrote:
> > [...]
> > > @@ -5299,6 +5300,26 @@ struct cgroup_subsys_state
> > > *cgroup_css_from_dir
On Mon 08-04-13 16:47:50, Michal Hocko wrote:
> On Mon 08-04-13 16:20:11, Li Zefan wrote:
> [...]
> > @@ -5299,6 +5300,26 @@ struct cgroup_subsys_state
> > *cgroup_css_from_dir(struct file *f, int id)
> > return css ? css : ERR_PTR(-ENOENT);
> > }
> >
On Mon 08-04-13 14:36:46, Tejun Heo wrote:
> On Mon, Apr 08, 2013 at 08:03:44PM +0200, Michal Hocko wrote:
> > __mem_cgroup_same_or_subtree relies on css_is_ancestor if hierarchy is
> > enabled for ages. This, however, is not correct because use_hierarchy
> > doesn't need
On Tue 09-04-13 11:02:20, Li Zefan wrote:
> On 2013/4/8 22:57, Michal Hocko wrote:
> > On Mon 08-04-13 16:22:11, Li Zefan wrote:
> >> This is a preparation to kill css_id.
> >>
> >> Signed-off-by: Li Zefan
> >
> > This patch depends on the follow
On Mon 08-04-13 16:21:14, Li Zefan wrote:
> This is a preparation to kill css_id.
>
> Signed-off-by: Li Zefan
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
5GB copied before I stop dd, but the used
> >pages which I monitor during dd always around 1200MB. Weird, why?
> >
>
> Sorry for waste your time, but the test result is weird, is it?
I am not sure which values you have been watching but you have to
realize that you are reading
as kswapd will
> reclaim excessively if it is to balance zones for high-order allocations.
>
> Signed-off-by: Mel Gorman
> Reviewed-by: Rik van Riel
> Acked-by: Johannes Weiner
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 53 +---
(pte)) ||
> ((flags & FOLL_WRITE) && !pte_write(huge_ptep_get(pte {
> int ret;
OK, 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
gt; for hwpoisoned ones.
>
> ChangeLog v5:
> - improve comment and description.
>
> ChangeLog v4:
> - move is_swap_page() to right place.
>
> ChangeLog v3:
> - add comment about using is_swap_pte()
>
> Signed-off-by: Naoya Horiguchi
> Cc: sta...@vger.kern
On Wed 02-01-13 11:44:21, Michal Hocko wrote:
> On Wed 26-12-12 01:26:07, Sha Zhengju wrote:
> > From: Sha Zhengju
> >
> > This patch adds memcg routines to count dirty pages, which allows memory
> > controller
> > to maintain an accurate view of the a
ic commit(s), please?
> Making requests for large amounts of memory from an allocator that is
> supposed to hand out fraction of a page does not make sense.
AFAIR there were lots of objects in size-512 as well.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line
orkfn()
Mel Gorman (2):
mm: page_alloc: avoid marking zones full prematurely after zone_reclaim()
mm: swap: mark swap pages writeback before queueing for direct IO
Michal Hocko (10):
memcg: fix memcg_cache_name() to use cgroup_name()
Merge remote-tracking branch 'tj-cgroup
m_cgroup() to return bool.
>
> Signed-off-by: David Rientjes
Well spotted!
Acked-by: Michal Hocko
Thanks
> ---
> include/linux/memcontrol.h | 9 +
> mm/memcontrol.c| 11 ++-
> 2 files changed, 11 insertions(+), 9 deletions(-)
>
> diff -
0 00 49 89 9c 24 48 0f 00 00 e9 0a
> [ 26.115282] RIP []
> __mem_cgroup_uncharge_common+0x255/0x2e0
> [ 26.115282] RSP
> [ 26.171597] ---[ end trace 5e49a21e51452c24 ]---
>
>
> mm/memcontrol:4111
> VM_BUG_ON(PageSwapCache(page));
>
> Seems that mem_cgroup_unch
Tue, Apr 23, 2013 at 03:15:58PM +0200, Michal Hocko wrote:
> > On Tue 23-04-13 12:22:34, Han Pingtian wrote:
> > > On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
> > > > [...]
> > > > > -CONFIG_SLUB_DEBUG=y
> > > > &g
apCache(page))
Maybe not many people run with CONFIG_DEBUG_VM enabled these days so we
do not this more often (even me testing configs are not consistent in
that regards and only few have it on). The only thing that changed in
this area recently is 0c59b89c which made the test VM_BUG_ON rather t
issue with the page allocator then.
You seem to have CONFIG_MEMCG_KMEM enabled. Do you see the same issue
when this is disabled? The kmem accounting should be disabled unless a
specific limit is set but it would be better to know that this is not
the factor.
--
Michal Hocko
SUSE Labs
--
To unsubsc
fected by bit 5-6.
> >
> > However current code can go into the subsequent flag checks of bit 0-4
> > for vma(VM_HUGETLB). So this patch inserts 'return' and makes it work
> > as written in the document.
> >
> > Signed-off-by: Naoya Horiguchi
>
ve processes at least. We can pin processes to
> > subsets of cores but I don't think there's a way to keep kswapd from
> > waking up on any of them?
>
> I've never tried it myself but does the following work?
>
> taskset -p MASK `pidof kswapd`
I would use
intended behavior. Limits are not propagated to the children
because they are enforced anyway (by reclaim). The behavior would
be quite inconsistent when the parent limit would be changed later
otherwise. We only inherit properties which are enforced hierarchically:
use_hierarchy, oom_disable and swappi
se?
It wasn't obvious, at least from me.
Other than that.
Acked-by: Michal Hocko
Thanks!
> Signed-off-by: Tejun Heo
> Cc: Michal Hocko
> Cc: KAMEZAWA Hiroyuki
> ---
> include/linux/cgroup.h | 3 +++
> mm/memcontrol.c| 13 +
> 2 files chan
you wanna route it.
You can route it via your tree as it seems like the simplest way.
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.ke
et's remove it.
>
> v2: Explain that mem_cgroup_bind() doesn't have to worry about
> children as suggested by Michal Hocko.
Thanks a lot Tejun!
>
> Signed-off-by: Tejun Heo
> Acked-by: Serge E. Hallyn
> Acked-by: Li Zefan
> Acked-by: Michal Hocko
> Ack
On Thu 16-05-13 15:12:00, Tejun Heo wrote:
> Sorry about the delay. Just getting back to memcg.
>
> On Mon, May 13, 2013 at 09:46:10AM +0200, Michal Hocko wrote:
> ...
> > during the first pass. Only groups which are over their soft limit or
> > any of their parents up t
the leader email into the first patch as he tend to do quite often in
other cases as well.
--
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 16-05-13 16:12:38, Tejun Heo wrote:
> On Mon, May 13, 2013 at 09:46:12AM +0200, Michal Hocko wrote:
> > Soft reclaim has been done only for the global reclaim (both background
> > and direct). Since "memcg: integrate soft reclaim tighter with zone
> > shrinking co
On Wed 15-05-13 12:42:10, Glauber Costa wrote:
> On 05/13/2013 11:46 AM, Michal Hocko wrote:
> > Soft reclaim has been done only for the global reclaim (both background
> > and direct). Since "memcg: integrate soft reclaim tighter with zone
> > shrinking code&qu
On Fri 17-05-13 14:11:26, Rafael J. Wysocki wrote:
> On Friday, May 17, 2013 09:54:46 AM Michal Hocko wrote:
> > On Wed 15-05-13 11:56:08, Michal Hocko wrote:
> > > OK, I have bisected it to 78d77df7 (x86-64, init: Do not set NX bits on
> > > non-NX capable hardware). Re
On Fri 17-05-13 14:23:51, Rafael J. Wysocki wrote:
> On Friday, May 17, 2013 02:09:30 PM Michal Hocko wrote:
> > On Fri 17-05-13 14:11:26, Rafael J. Wysocki wrote:
> > > On Friday, May 17, 2013 09:54:46 AM Michal Hocko wrote:
> > > > On Wed 15-05-13 11:56:08, Micha
On Fri 17-05-13 12:02:47, Johannes Weiner wrote:
> On Mon, May 13, 2013 at 09:46:10AM +0200, Michal Hocko wrote:
> > Memcg soft reclaim has been traditionally triggered from the global
> > reclaim paths before calling shrink_zone. mem_cgroup_soft_limit_reclaim
> > then pi
x27;t suspended in RAM at
all.
References: https://lkml.org/lkml/2013/5/14/398
Cc: sta...@vger.kernel.org # 3.9
Signed-off-by: Michal Hocko
---
arch/x86/kernel/head64.c |3 +--
arch/x86/kernel/head_64.S |1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kernel/head6
On Mon 20-05-13 10:21:09, Linus Torvalds wrote:
> On Mon, May 20, 2013 at 9:43 AM, Michal Hocko wrote:
> >
> > The configuration has been posted in the referenced thread:
> > https://lkml.org/lkml/2013/5/14/398
>
> Hmm. That's a regular intel i5 Sandybridge CPU.
On Mon 20-05-13 11:30:31, H. Peter Anvin wrote:
> On 05/20/2013 11:23 AM, Michal Hocko wrote:
> > On Mon 20-05-13 10:21:09, Linus Torvalds wrote:
> >> On Mon, May 20, 2013 at 9:43 AM, Michal Hocko wrote:
> >>>
> >>> The configuration has been po
On Mon 20-05-13 16:44:38, Michal Hocko wrote:
[...]
> I had one group (call it A) with the streaming IO load (dd if=/dev/zero
> of=file with 4*TotalRam size) and a parallel hierarchy with 2 groups
> with up to 12 levels each (512, 1024, 4096, 8192 groups) and no limit
> set. I have
On Wed 22-05-13 11:56:38, Andrew Vagin wrote:
> On Wed, May 22, 2013 at 03:50:24PM +0800, Li Zefan wrote:
> > On 2013/5/22 15:40, Andrew Vagin wrote:
> > > On Tue, May 14, 2013 at 06:08:59PM +0200, Michal Hocko wrote:
> > >>
> > >> Forgot to add
> >
t would have been more
straightforward to show number of HighTotal before hotremove, show how
much memory has been removed and the number after.
It is not clear which stable kernels need this fix as well.
>
> Signed-off-by: Wanpeng Li
Anyway
Reviewed-by: Michal Hocko
with a nit pick b
On Wed 22-05-13 17:29:28, Wanpeng Li wrote:
> get_pageblock_flags and set_pageblock_flags are not used any
> more, this patch remove them.
>
> Signed-off-by: Wanpeng Li
Yes, git grep agrees
Reviewed-by: Michal Hocko
> ---
> include/linux/pageblock-flags.h | 6 --
&g
On Wed 22-05-13 17:29:29, Wanpeng Li wrote:
> hugetlb_prefault are not used any more, this patch remove it.
>
> Signed-off-by: Wanpeng Li
Reviewed-by: Michal Hocko
> ---
> include/linux/hugetlb.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/l
On Wed 22-05-13 17:29:30, Wanpeng Li wrote:
> Use already exist interface huge_page_shift instead of h->order + PAGE_SHIFT.
alloc_bootmem_huge_page in powerpc uses the same construct so maybe you
want to udpate that one as well.
>
> Signed-off-by: Wanpeng Li
Reviewed-by:
ions.
As I have copied my comment from the earlier thread above.
css_get does atomic_add which doesn't imply any barrier AFAIK and
memcg_kmem_mark_dead uses a simple set_bit which doesn't imply it
either. What am I missing?
> >
>
> Yeah, I think you're right.
>
&g
int nid = mi->blk[0].nid;
> - int i;
> -
> - for (i = 0; i < mi->nr_blks; i++)
> - if (mi->blk[i].start <= start && mi->blk[i].end > start)
> - nid = mi->blk[i].nid;
> - return nid;
> -}
> -EXPORT_
bool "Allow for memory hot remove"
> select MEMORY_ISOLATION
> select HAVE_BOOTMEM_INFO_NODE if X86_64
> + depends on 64BIT
> depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
> depends on MIGRATION
>
> --
> 1
y overall.
>
> And, yes, this patch is no good. Kconfig doesn't describe why disable
> when highmem.
> So,
>
> depends on 64BIT || !HIGHMEM || BROKEN
>
> maybe clear documentation more.
I have no objection to disbale the feature for HIGHMEM configurations I
was merely co
On Sun 26-05-13 17:06:17, Wanpeng Li wrote:
> On Sun, May 26, 2013 at 11:00:54AM +0200, Michal Hocko wrote:
> >On Sun 26-05-13 13:58:38, Wanpeng Li wrote:
> >> As KOSAKI Motohiro mentioned, memory hotplug don't support 32bit since
> >> it was born,
> >
&g
On Mon 27-05-13 07:51:38, Wanpeng Li wrote:
> On Sun, May 26, 2013 at 08:12:09PM +0200, Michal Hocko wrote:
> >On Sun 26-05-13 17:06:17, Wanpeng Li wrote:
> >> On Sun, May 26, 2013 at 11:00:54AM +0200, Michal Hocko wrote:
> >> >On Sun 26-05-13 13:58:38, Wanpeng Li wro
Hi,
it took me a bit longer than I wanted but I was closed in a conference
room in the end of the last week so I didn't have much time.
On Mon 20-05-13 16:44:38, Michal Hocko wrote:
> On Fri 17-05-13 12:02:47, Johannes Weiner wrote:
> > On Mon, May 13, 2013 at 09:46:10AM +0200, Mich
. The transition phase is recorded
in soft_contributed flag.
mem_cgroup_soft_reclaim_eligible then uses this information to better
decide whether to skip the node or the whole subtree. The rule is
simple. Skip the node with a children in excess or skip the whole subtree
otherwise.
Signed-off-by: M
zation is necessary.
Signed-off-by: Michal Hocko
---
mm/memcontrol.c |9 +
1 file changed, 9 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 592df10..7fb063f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -932,9 +932,15 @@ static void mem_cgroup_update_s
that we do not export root_mem_cgroup?
Signed-off-by: Michal Hocko
---
include/linux/memcontrol.h |2 ++
mm/memcontrol.c|2 +-
mm/vmscan.c|5 -
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/
Oh, forgot to post the first patch...
---
>From 54b422ba96e3fa9264ee308c4fd9d5fe36efde63 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Mon, 20 May 2013 13:40:11 +0200
Subject: [PATCH] memcg: enhance memcg iterator to support predicates
The caller of the iterator might know that some nodes
Ryan
> --
> 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/
--
Mic
ht after
kmem_cache_create_memcg makes a copy of it. Such a short-lived
allocation doesn't make too much sense. So replace it by a static
buffer as kmem_cache_dup is called with memcg_cache_mutex.
Signed-off-by: Li Zefan
Signed-off-by: Michal Hocko
Acked-by: Glauber Costa
---
mm/memcon
e patch you provided:
> >
> > Acked-by: Glauber Costa
> >
>
> Michal, could you resend your final patch to Tejun in a new mail thread?
> There are quite a few different patches inlined in this thread.
Done.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this
ate_huge_page(), we passed a hugepage to be migrated
> as an argument, so the caller can still access to the page even if the
> migration succeeds.
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
ve put_page should remove the last reference and then it
will uncharge it but I do not see anything that would charge a new page.
This is all because regula LRU pages are uncharged when they are
unmapped. But this a different story not related to this series.
[...]
--
Michal Hocko
S
On Tue 26-03-13 14:23:24, Naoya Horiguchi wrote:
> On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
> > On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
> ...
> > > index d9d3dd7..ef79871 100644
> > > --- v3.9-rc3.orig/mm/hugetlb.c
> > > ++
On Wed 27-03-13 10:58:25, Johannes Weiner wrote:
> On Wed, Mar 27, 2013 at 09:36:39AM +0100, Michal Hocko wrote:
[...]
> > + /*
> > +* kmem_cache_create_memcg duplicates the given name and
> > +* cgroup_name for this name requires RCU context.
> > +* This
On Wed 27-03-13 19:19:58, Glauber Costa wrote:
> On 03/27/2013 07:11 PM, Michal Hocko wrote:
> > On Wed 27-03-13 10:58:25, Johannes Weiner wrote:
> >> On Wed, Mar 27, 2013 at 09:36:39AM +0100, Michal Hocko wrote:
> > [...]
> >>> + /*
> >>> + * kmem_
On Wed 27-03-13 11:32:26, Johannes Weiner wrote:
> On Wed, Mar 27, 2013 at 04:11:04PM +0100, Michal Hocko wrote:
> > On Wed 27-03-13 10:58:25, Johannes Weiner wrote:
> > > On Wed, Mar 27, 2013 at 09:36:39AM +0100,
On Wed 27-03-13 09:15:27, Tejun Heo wrote:
> On Wed, Mar 27, 2013 at 09:36:39AM +0100, Michal Hocko wrote:
> > +/*
> > + * Called with memcg_cache_mutex held
> > + */
> > static struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg,
> >
On Wed 27-03-13 09:21:02, Tejun Heo wrote:
> On Wed, Mar 27, 2013 at 9:19 AM, Michal Hocko wrote:
> >> Maybe the name could signify it's part of memcg?
> >
> > kmem_ prefix is used for all CONFIG_MEMCG_KMEM functions. I understand
> > it clashes with sl?b nami
On Wed 27-03-13 16:32:20, Michal Hocko wrote:
> On Wed 27-03-13 19:19:58, Glauber Costa wrote:
> > On 03/27/2013 07:11 PM, Michal Hocko wrote:
> > > On Wed 27-03-13 10:58:25, Johannes Weiner wrote:
> > >> On Wed, Mar 27, 2013 at 09:36:
On Wed 27-03-13 17:29:19, Naoya Horiguchi wrote:
> On Wed, Mar 27, 2013 at 03:19:21PM +0100, Michal Hocko wrote:
[...]
> > If we made sure that all page on the hugepage_freelists have reference
> > 0 (which is now not the case and it is yet another source of confusion)
> >
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's acked-by but I
> can remove it.
And hopefully the last version. I forgot to s/PAGE_SIZE/MA
801 - 900 of 11648 matches
Mail list logo
