[PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[Chen Gang]

When !MMU, it will report warning. The related warning with allmodconfig
under c6x:

    CC      mm/memcontrol.o
  mm/memcontrol.c:2802:12: warning: 'mem_cgroup_move_account' defined but not used [-Wunused-function]
   static int mem_cgroup_move_account(struct page *page,
              ^

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 mm/memcontrol.c | 172 ++++++++++++++++++++++++++++----------------------------
 1 file changed, 86 insertions(+), 86 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 0c86945..80f26f5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2785,92 +2785,6 @@ void mem_cgroup_split_huge_fixup(struct page *head)
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-/**
- * mem_cgroup_move_account - move account of the page
- * @page: the page
- * @nr_pages: number of regular pages (>1 for huge pages)
- * @from: mem_cgroup which the page is moved from.
- * @to:	mem_cgroup which the page is moved to. @from != @to.
- *
- * The caller must confirm following.
- * - page is not on LRU (isolate_page() is useful.)
- * - compound_lock is held when nr_pages > 1
- *
- * This function doesn't do "charge" to new cgroup and doesn't do "uncharge"
- * from old cgroup.
- */
-static int mem_cgroup_move_account(struct page *page,
-				   unsigned int nr_pages,
-				   struct mem_cgroup *from,
-				   struct mem_cgroup *to)
-{
-	unsigned long flags;
-	int ret;
-
-	VM_BUG_ON(from == to);
-	VM_BUG_ON_PAGE(PageLRU(page), page);
-	/*
-	 * The page is isolated from LRU. So, collapse function
-	 * will not handle this page. But page splitting can happen.
-	 * Do this check under compound_page_lock(). The caller should
-	 * hold it.
-	 */
-	ret = -EBUSY;
-	if (nr_pages > 1 && !PageTransHuge(page))
-		goto out;
-
-	/*
-	 * Prevent mem_cgroup_migrate() from looking at page->mem_cgroup
-	 * of its source page while we change it: page migration takes
-	 * both pages off the LRU, but page cache replacement doesn't.
-	 */
-	if (!trylock_page(page))
-		goto out;
-
-	ret = -EINVAL;
-	if (page->mem_cgroup != from)
-		goto out_unlock;
-
-	spin_lock_irqsave(&from->move_lock, flags);
-
-	if (!PageAnon(page) && page_mapped(page)) {
-		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
-			       nr_pages);
-		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
-			       nr_pages);
-	}
-
-	if (PageWriteback(page)) {
-		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_WRITEBACK],
-			       nr_pages);
-		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_WRITEBACK],
-			       nr_pages);
-	}
-
-	/*
-	 * It is safe to change page->mem_cgroup here because the page
-	 * is referenced, charged, and isolated - we can't race with
-	 * uncharging, charging, migration, or LRU putback.
-	 */
-
-	/* caller should have done css_get */
-	page->mem_cgroup = to;
-	spin_unlock_irqrestore(&from->move_lock, flags);
-
-	ret = 0;
-
-	local_irq_disable();
-	mem_cgroup_charge_statistics(to, page, nr_pages);
-	memcg_check_events(to, page);
-	mem_cgroup_charge_statistics(from, page, -nr_pages);
-	memcg_check_events(from, page);
-	local_irq_enable();
-out_unlock:
-	unlock_page(page);
-out:
-	return ret;
-}
-
 #ifdef CONFIG_MEMCG_SWAP
 static void mem_cgroup_swap_statistics(struct mem_cgroup *memcg,
 					 bool charge)
@@ -4822,6 +4736,92 @@ static struct page *mc_handle_file_pte(struct vm_area_struct *vma,
 	return page;
 }
 
+/**
+ * mem_cgroup_move_account - move account of the page
+ * @page: the page
+ * @nr_pages: number of regular pages (>1 for huge pages)
+ * @from: mem_cgroup which the page is moved from.
+ * @to:	mem_cgroup which the page is moved to. @from != @to.
+ *
+ * The caller must confirm following.
+ * - page is not on LRU (isolate_page() is useful.)
+ * - compound_lock is held when nr_pages > 1
+ *
+ * This function doesn't do "charge" to new cgroup and doesn't do "uncharge"
+ * from old cgroup.
+ */
+static int mem_cgroup_move_account(struct page *page,
+				   unsigned int nr_pages,
+				   struct mem_cgroup *from,
+				   struct mem_cgroup *to)
+{
+	unsigned long flags;
+	int ret;
+
+	VM_BUG_ON(from == to);
+	VM_BUG_ON_PAGE(PageLRU(page), page);
+	/*
+	 * The page is isolated from LRU. So, collapse function
+	 * will not handle this page. But page splitting can happen.
+	 * Do this check under compound_page_lock(). The caller should
+	 * hold it.
+	 */
+	ret = -EBUSY;
+	if (nr_pages > 1 && !PageTransHuge(page))
+		goto out;
+
+	/*
+	 * Prevent mem_cgroup_migrate() from looking at page->mem_cgroup
+	 * of its source page while we change it: page migration takes
+	 * both pages off the LRU, but page cache replacement doesn't.
+	 */
+	if (!trylock_page(page))
+		goto out;
+
+	ret = -EINVAL;
+	if (page->mem_cgroup != from)
+		goto out_unlock;
+
+	spin_lock_irqsave(&from->move_lock, flags);
+
+	if (!PageAnon(page) && page_mapped(page)) {
+		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
+			       nr_pages);
+		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
+			       nr_pages);
+	}
+
+	if (PageWriteback(page)) {
+		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_WRITEBACK],
+			       nr_pages);
+		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_WRITEBACK],
+			       nr_pages);
+	}
+
+	/*
+	 * It is safe to change page->mem_cgroup here because the page
+	 * is referenced, charged, and isolated - we can't race with
+	 * uncharging, charging, migration, or LRU putback.
+	 */
+
+	/* caller should have done css_get */
+	page->mem_cgroup = to;
+	spin_unlock_irqrestore(&from->move_lock, flags);
+
+	ret = 0;
+
+	local_irq_disable();
+	mem_cgroup_charge_statistics(to, page, nr_pages);
+	memcg_check_events(to, page);
+	mem_cgroup_charge_statistics(from, page, -nr_pages);
+	memcg_check_events(from, page);
+	local_irq_enable();
+out_unlock:
+	unlock_page(page);
+out:
+	return ret;
+}
+
 static enum mc_target_type get_mctgt_type(struct vm_area_struct *vma,
 		unsigned long addr, pte_t ptent, union mc_target *target)
 {
-- 
1.9.3


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[Michal Hocko]

On Tue 03-03-15 06:42:01, Chen Gang wrote:
> When !MMU, it will report warning. The related warning with allmodconfig
> under c6x:

Does it even make any sense to enable CONFIG_MEMCG when !CONFIG_MMU?
Is anybody using this configuration and is it actually usable? My
knowledge about CONFIG_MMU is close to zero so I might be missing
something but I do not see a point into fixing compile warnings when
the whole subsystem is not usable in the first place.

> 
>     CC      mm/memcontrol.o
>   mm/memcontrol.c:2802:12: warning: 'mem_cgroup_move_account' defined but not used [-Wunused-function]
>    static int mem_cgroup_move_account(struct page *page,
>               ^
> 
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
>  mm/memcontrol.c | 172 ++++++++++++++++++++++++++++----------------------------
>  1 file changed, 86 insertions(+), 86 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 0c86945..80f26f5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2785,92 +2785,6 @@ void mem_cgroup_split_huge_fixup(struct page *head)
>  }
>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  
> -/**
> - * mem_cgroup_move_account - move account of the page
> - * @page: the page
> - * @nr_pages: number of regular pages (>1 for huge pages)
> - * @from: mem_cgroup which the page is moved from.
> - * @to:	mem_cgroup which the page is moved to. @from != @to.
> - *
> - * The caller must confirm following.
> - * - page is not on LRU (isolate_page() is useful.)
> - * - compound_lock is held when nr_pages > 1
> - *
> - * This function doesn't do "charge" to new cgroup and doesn't do "uncharge"
> - * from old cgroup.
> - */
> -static int mem_cgroup_move_account(struct page *page,
> -				   unsigned int nr_pages,
> -				   struct mem_cgroup *from,
> -				   struct mem_cgroup *to)
> -{
> -	unsigned long flags;
> -	int ret;
> -
> -	VM_BUG_ON(from == to);
> -	VM_BUG_ON_PAGE(PageLRU(page), page);
> -	/*
> -	 * The page is isolated from LRU. So, collapse function
> -	 * will not handle this page. But page splitting can happen.
> -	 * Do this check under compound_page_lock(). The caller should
> -	 * hold it.
> -	 */
> -	ret = -EBUSY;
> -	if (nr_pages > 1 && !PageTransHuge(page))
> -		goto out;
> -
> -	/*
> -	 * Prevent mem_cgroup_migrate() from looking at page->mem_cgroup
> -	 * of its source page while we change it: page migration takes
> -	 * both pages off the LRU, but page cache replacement doesn't.
> -	 */
> -	if (!trylock_page(page))
> -		goto out;
> -
> -	ret = -EINVAL;
> -	if (page->mem_cgroup != from)
> -		goto out_unlock;
> -
> -	spin_lock_irqsave(&from->move_lock, flags);
> -
> -	if (!PageAnon(page) && page_mapped(page)) {
> -		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
> -			       nr_pages);
> -		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
> -			       nr_pages);
> -	}
> -
> -	if (PageWriteback(page)) {
> -		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_WRITEBACK],
> -			       nr_pages);
> -		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_WRITEBACK],
> -			       nr_pages);
> -	}
> -
> -	/*
> -	 * It is safe to change page->mem_cgroup here because the page
> -	 * is referenced, charged, and isolated - we can't race with
> -	 * uncharging, charging, migration, or LRU putback.
> -	 */
> -
> -	/* caller should have done css_get */
> -	page->mem_cgroup = to;
> -	spin_unlock_irqrestore(&from->move_lock, flags);
> -
> -	ret = 0;
> -
> -	local_irq_disable();
> -	mem_cgroup_charge_statistics(to, page, nr_pages);
> -	memcg_check_events(to, page);
> -	mem_cgroup_charge_statistics(from, page, -nr_pages);
> -	memcg_check_events(from, page);
> -	local_irq_enable();
> -out_unlock:
> -	unlock_page(page);
> -out:
> -	return ret;
> -}
> -
>  #ifdef CONFIG_MEMCG_SWAP
>  static void mem_cgroup_swap_statistics(struct mem_cgroup *memcg,
>  					 bool charge)
> @@ -4822,6 +4736,92 @@ static struct page *mc_handle_file_pte(struct vm_area_struct *vma,
>  	return page;
>  }
>  
> +/**
> + * mem_cgroup_move_account - move account of the page
> + * @page: the page
> + * @nr_pages: number of regular pages (>1 for huge pages)
> + * @from: mem_cgroup which the page is moved from.
> + * @to:	mem_cgroup which the page is moved to. @from != @to.
> + *
> + * The caller must confirm following.
> + * - page is not on LRU (isolate_page() is useful.)
> + * - compound_lock is held when nr_pages > 1
> + *
> + * This function doesn't do "charge" to new cgroup and doesn't do "uncharge"
> + * from old cgroup.
> + */
> +static int mem_cgroup_move_account(struct page *page,
> +				   unsigned int nr_pages,
> +				   struct mem_cgroup *from,
> +				   struct mem_cgroup *to)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	VM_BUG_ON(from == to);
> +	VM_BUG_ON_PAGE(PageLRU(page), page);
> +	/*
> +	 * The page is isolated from LRU. So, collapse function
> +	 * will not handle this page. But page splitting can happen.
> +	 * Do this check under compound_page_lock(). The caller should
> +	 * hold it.
> +	 */
> +	ret = -EBUSY;
> +	if (nr_pages > 1 && !PageTransHuge(page))
> +		goto out;
> +
> +	/*
> +	 * Prevent mem_cgroup_migrate() from looking at page->mem_cgroup
> +	 * of its source page while we change it: page migration takes
> +	 * both pages off the LRU, but page cache replacement doesn't.
> +	 */
> +	if (!trylock_page(page))
> +		goto out;
> +
> +	ret = -EINVAL;
> +	if (page->mem_cgroup != from)
> +		goto out_unlock;
> +
> +	spin_lock_irqsave(&from->move_lock, flags);
> +
> +	if (!PageAnon(page) && page_mapped(page)) {
> +		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
> +			       nr_pages);
> +		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_FILE_MAPPED],
> +			       nr_pages);
> +	}
> +
> +	if (PageWriteback(page)) {
> +		__this_cpu_sub(from->stat->count[MEM_CGROUP_STAT_WRITEBACK],
> +			       nr_pages);
> +		__this_cpu_add(to->stat->count[MEM_CGROUP_STAT_WRITEBACK],
> +			       nr_pages);
> +	}
> +
> +	/*
> +	 * It is safe to change page->mem_cgroup here because the page
> +	 * is referenced, charged, and isolated - we can't race with
> +	 * uncharging, charging, migration, or LRU putback.
> +	 */
> +
> +	/* caller should have done css_get */
> +	page->mem_cgroup = to;
> +	spin_unlock_irqrestore(&from->move_lock, flags);
> +
> +	ret = 0;
> +
> +	local_irq_disable();
> +	mem_cgroup_charge_statistics(to, page, nr_pages);
> +	memcg_check_events(to, page);
> +	mem_cgroup_charge_statistics(from, page, -nr_pages);
> +	memcg_check_events(from, page);
> +	local_irq_enable();
> +out_unlock:
> +	unlock_page(page);
> +out:
> +	return ret;
> +}
> +
>  static enum mc_target_type get_mctgt_type(struct vm_area_struct *vma,
>  		unsigned long addr, pte_t ptent, union mc_target *target)
>  {
> -- 
> 1.9.3
> 
> 

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[Chen Gang]

On 3/3/15 21:45, Michal Hocko wrote:
> On Tue 03-03-15 06:42:01, Chen Gang wrote:
>> When !MMU, it will report warning. The related warning with allmodconfig
>> under c6x:
> 
> Does it even make any sense to enable CONFIG_MEMCG when !CONFIG_MMU?
> Is anybody using this configuration and is it actually usable? My
> knowledge about CONFIG_MMU is close to zero so I might be missing
> something but I do not see a point into fixing compile warnings when
> the whole subsystem is not usable in the first place.
> 

For me, only according to the current code, the original author assumes
CONFIG_MEMCG can still have effect when !CONFIG_MMU: "or, he/she needn't
use CONFIG_MMU switch macro in memcontrol.c".

Welcome any other members' ideas, too.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[Michal Hocko]

[CCing Balbir]

On Wed 04-03-15 04:01:04, Chen Gang wrote:
> On 3/3/15 21:45, Michal Hocko wrote:
> > On Tue 03-03-15 06:42:01, Chen Gang wrote:
> >> When !MMU, it will report warning. The related warning with allmodconfig
> >> under c6x:
> > 
> > Does it even make any sense to enable CONFIG_MEMCG when !CONFIG_MMU?
> > Is anybody using this configuration and is it actually usable? My
> > knowledge about CONFIG_MMU is close to zero so I might be missing
> > something but I do not see a point into fixing compile warnings when
> > the whole subsystem is not usable in the first place.
> > 
> 
> For me, only according to the current code, the original author assumes
> CONFIG_MEMCG can still have effect when !CONFIG_MMU: "or, he/she needn't
> use CONFIG_MMU switch macro in memcontrol.c".

Well this was before my time. 024914477e15 (memcg: move charges of
anonymous swap) added them because of lack of page tables (as per
documentation). This is a good reason but a bigger question is whether
we want to add small little changes to make compiler happy or face the
reality and realize that MEMCG without MMU is so restricted (I am even
not sure whether it is usable at all) and reflect that in the
dependency. Balbir had actually mentioned this in early submissions:
https://lkml.org/lkml/2008/3/16/59. I haven't seen anybody objecting to
this so I guess it went in without a good reason. So instead I suggest
the following change instead.
---

Re: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[Johannes Weiner]

On Tue, Mar 03, 2015 at 02:45:24PM +0100, Michal Hocko wrote:
> On Tue 03-03-15 06:42:01, Chen Gang wrote:
> > When !MMU, it will report warning. The related warning with allmodconfig
> > under c6x:
> 
> Does it even make any sense to enable CONFIG_MEMCG when !CONFIG_MMU?
> Is anybody using this configuration and is it actually usable? My
> knowledge about CONFIG_MMU is close to zero so I might be missing
> something but I do not see a point into fixing compile warnings when
> the whole subsystem is not usable in the first place.

It's very limited, and anonymous memory is not even charged right now,
even though it could be -- see nommu.c::do_mmap_private().  But there
is nothing inherent in the memcg functionality that would require an
MMU I guess, except for these ridiculous charge moving pte walkers.

> > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm: memcontrol: Let mem_cgroup_move_account() have effect only if MMU enabled

[Michal Hocko]

On Wed 04-03-15 12:40:56, Johannes Weiner wrote:
> On Tue, Mar 03, 2015 at 02:45:24PM +0100, Michal Hocko wrote:
> > On Tue 03-03-15 06:42:01, Chen Gang wrote:
> > > When !MMU, it will report warning. The related warning with allmodconfig
> > > under c6x:
> > 
> > Does it even make any sense to enable CONFIG_MEMCG when !CONFIG_MMU?
> > Is anybody using this configuration and is it actually usable? My
> > knowledge about CONFIG_MMU is close to zero so I might be missing
> > something but I do not see a point into fixing compile warnings when
> > the whole subsystem is not usable in the first place.
> 
> It's very limited, and anonymous memory is not even charged right now,
> even though it could be -- see nommu.c::do_mmap_private().  But there
> is nothing inherent in the memcg functionality that would require an
> MMU I guess, except for these ridiculous charge moving pte walkers.
> 
> > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> 
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Thanks, I will post the patch to Andrew.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>