[PATCH] Handling of unused variable 'do-numainfo on compilation time

[PATCH] Handling of unused variable 'do-numainfo on compilation time

[Geunsik Lim]

Actually, Usage of the variable 'do_numainfo'is not suitable for gcc compiler.
Declare the variable 'do_numainfo' if the number of NUMA nodes > 1.

Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
---
 mm/memcontrol.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 556859f..4e17ac5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -776,7 +776,10 @@ static void memcg_check_events(struct mem_cgroup *memcg, struct page *page)
 	/* threshold event is triggered in finer grain than soft limit */
 	if (unlikely(mem_cgroup_event_ratelimit(memcg,
 						MEM_CGROUP_TARGET_THRESH))) {
-		bool do_softlimit, do_numainfo;
+		bool do_softlimit;
+#if MAX_NUMNODES > 1
+                bool do_numainfo;
+#endif
 
 		do_softlimit = mem_cgroup_event_ratelimit(memcg,
 						MEM_CGROUP_TARGET_SOFTLIMIT);
-- 
1.7.8.1

Re: [PATCH] Handling of unused variable 'do-numainfo on compilation time

[Johannes Weiner]

Michal, this keeps coming up, please decide between the proposed
solutions ;-)

On Fri, Feb 03, 2012 at 05:43:47PM +0900, Geunsik Lim wrote:
> Actually, Usage of the variable 'do_numainfo'is not suitable for gcc compiler.
> Declare the variable 'do_numainfo' if the number of NUMA nodes > 1.
> 
> Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
> ---
>  mm/memcontrol.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 556859f..4e17ac5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -776,7 +776,10 @@ static void memcg_check_events(struct mem_cgroup *memcg, struct page *page)
>  	/* threshold event is triggered in finer grain than soft limit */
>  	if (unlikely(mem_cgroup_event_ratelimit(memcg,
>  						MEM_CGROUP_TARGET_THRESH))) {
> -		bool do_softlimit, do_numainfo;
> +		bool do_softlimit;
> +#if MAX_NUMNODES > 1
> +                bool do_numainfo;
> +#endif
>  
>  		do_softlimit = mem_cgroup_event_ratelimit(memcg,
>  						MEM_CGROUP_TARGET_SOFTLIMIT);
> -- 
> 1.7.8.1
> 

Re: [PATCH] Handling of unused variable 'do-numainfo on compilation time

[Michal Hocko]

On Fri 03-02-12 14:39:50, Johannes Weiner wrote:
> Michal, this keeps coming up, please decide between the proposed
> solutions ;-)

Hmm, I thought we already sorted this out https://lkml.org/lkml/2012/1/26/25 ?

> 
> On Fri, Feb 03, 2012 at 05:43:47PM +0900, Geunsik Lim wrote:
> > Actually, Usage of the variable 'do_numainfo'is not suitable for gcc compiler.
> > Declare the variable 'do_numainfo' if the number of NUMA nodes > 1.
> > 
> > Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
> > ---
> >  mm/memcontrol.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 556859f..4e17ac5 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -776,7 +776,10 @@ static void memcg_check_events(struct mem_cgroup *memcg, struct page *page)
> >  	/* threshold event is triggered in finer grain than soft limit */
> >  	if (unlikely(mem_cgroup_event_ratelimit(memcg,
> >  						MEM_CGROUP_TARGET_THRESH))) {
> > -		bool do_softlimit, do_numainfo;
> > +		bool do_softlimit;
> > +#if MAX_NUMNODES > 1
> > +                bool do_numainfo;
> > +#endif
> >  
> >  		do_softlimit = mem_cgroup_event_ratelimit(memcg,
> >  						MEM_CGROUP_TARGET_SOFTLIMIT);
> > -- 
> > 1.7.8.1
> > 

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: [PATCH] Handling of unused variable 'do-numainfo on compilation time

[Michal Hocko]

On Sat 04-02-12 00:36:36, Geunsik Lim wrote:
> On Fri, Feb 3, 2012 at 11:53 PM, Michal Hocko <mhocko@suse.cz> wrote:
> 
> > On Fri 03-02-12 14:39:50, Johannes Weiner wrote:
> > > Michal, this keeps coming up, please decide between the proposed
> > > solutions ;-)
> >
> > Hmm, I thought we already sorted this out
> > https://lkml.org/lkml/2012/1/26/25 ?
> >
> I don't know previous history about this variable.
> Is it same? Please, adjust this patch or fix the unsuitable
> variable 'do_numainfo' as I mentioned.

The patch (I guess the author is Andrew) just silence the compiler
warning which is the easiest fix in this case because we know it will be
used only for MAX_NUMNODES > 1.
Your patch fixes it as well but it adds an ugly ifdef around the
variable.

Andrew, could you pick up this one, please?
---
>From 9fe9ae356ace2daf9529bb8cfa2e20bef7c415af Mon Sep 17 00:00:00 2001
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 3 Feb 2012 16:58:19 +0100
Subject: [PATCH] memcg: memcg_check_events: silent unused variable warning

do_numainfo is used only if MAX_NUMNODES > 1 so we have a following
warning for UMA machines.

CC      mm/memcontrol.o
mm/memcontrol.c: In function 'memcg_check_events':
mm/memcontrol.c:779:22: warning: unused variable 'do_numainfo'

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
---
 mm/memcontrol.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index bf29761..5f805cc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -708,7 +708,8 @@ static void memcg_check_events(struct mem_cgroup *memcg, struct page *page)
 	/* threshold event is triggered in finer grain than soft limit */
 	if (unlikely(mem_cgroup_event_ratelimit(memcg,
 						MEM_CGROUP_TARGET_THRESH))) {
-		bool do_softlimit, do_numainfo;
+		bool do_softlimit;
+		bool do_numainfo __maybe_unused;
 
 		do_softlimit = mem_cgroup_event_ratelimit(memcg,
 						MEM_CGROUP_TARGET_SOFTLIMIT);
-- 
1.7.8.3


-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: [PATCH] Handling of unused variable 'do-numainfo on compilation time

[Johannes Weiner]

On Fri, Feb 03, 2012 at 03:53:04PM +0100, Michal Hocko wrote:
> On Fri 03-02-12 14:39:50, Johannes Weiner wrote:
> > Michal, this keeps coming up, please decide between the proposed
> > solutions ;-)
> 
> Hmm, I thought we already sorted this out https://lkml.org/lkml/2012/1/26/25 ?

Hah.  Sorry, I missed that.