2012-02-03 08:43:55

by Geunsik Lim

[permalink] [raw]
Subject: [PATCH] Handling of unused variable 'do-numainfo on compilation time

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 <[email protected]>
---
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


2012-02-03 13:40:04

by Johannes Weiner

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

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 <[email protected]>
> ---
> 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
>

2012-02-03 14:53:09

by Michal Hocko

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

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 <[email protected]>
> > ---
> > 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

2012-02-03 16:04:36

by Michal Hocko

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

On Sat 04-02-12 00:36:36, Geunsik Lim wrote:
> On Fri, Feb 3, 2012 at 11:53 PM, Michal Hocko <[email protected]> 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 <[email protected]>
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 <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
---
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

2012-02-03 16:06:50

by Johannes Weiner

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

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.