> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
> value of funtions by u64 to avoid overflow.

>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>> value of funtions by u64 to avoid overflow.

>I wonder what 16 TB of memory must think running on a 32-bit kernel...
>"What is this, an address space for ants?"

> >> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
> >> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
> >> value of funtions by u64 to avoid overflow.

> >I wonder what 16 TB of memory must think running on a 32-bit kernel...
> >"What is this, an address space for ants?"

> Hi Johannes,

> You mean change all u64 in memcg to unsigned long? or something I
> miss....

>>>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>>>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>>>> value of funtions by u64 to avoid overflow.

>>> I wonder what 16 TB of memory must think running on a 32-bit kernel...
>>> "What is this, an address space for ants?"

>> Hi Johannes,

>> You mean change all u64 in memcg to unsigned long? or something I
>> miss....

> Not _all_ of them, we have some that count bytes.  But those counting
> pages should probably be ulong, yes.

> I think Kame added the ones that you wanted to adjust the surroundings
> for in particular, so let's ask him.  Kame?

>>>>>Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>>>>>mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>>>>>value of funtions by u64 to avoid overflow.

>>>>I wonder what 16 TB of memory must think running on a 32-bit kernel...
>>>>"What is this, an address space for ants?"

>>>Hi Johannes,

>>>You mean change all u64 in memcg to unsigned long? or something I
>>>miss....

>>Not _all_ of them, we have some that count bytes.  But those counting
>>pages should probably be ulong, yes.

>>I think Kame added the ones that you wanted to adjust the surroundings
>>for in particular, so let's ask him.  Kame?

>I've been using 'unsigned long' for the number of pages and 'u64' for the number of
>bytes. I think it's enough and it should be. I don't have any reason to use u64 for
>the number of pages on 32bit archs.
>If 'bytes' are handled by 'unsigned long', please fix it.

>BTW, zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'.
>If you want to change this in memcg, please change zone's ones first.

>Thanks,
>-Kame

> V2 -> V1:
> * fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'

> From: Wanpeng Li <l...@linux.vnet.ibm.com>

> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
> value of funtions by u64 to avoid overflow.

> Signed-off-by: Wanpeng Li <liwp.li...@gmail.com>
> ---
>  include/linux/vmstat.h |    2 +-
>  mm/memcontrol.c        |    5 ++---
>  2 files changed, 3 insertions(+), 4 deletions(-)

> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> index 65efb92..6a14291 100644
> --- a/include/linux/vmstat.h
> +++ b/include/linux/vmstat.h
> @@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
>    return x;
>  }

> -static inline unsigned long zone_page_state(struct zone *zone,
> +static inline u64 zone_page_state(struct zone *zone,
>                                    enum zone_stat_item item)
>  {
>    long x = atomic_long_read(&zone->vm_stat[item]);

>> V2 -> V1:
>> * fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'

>> From: Wanpeng Li <l...@linux.vnet.ibm.com>

>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>> value of funtions by u64 to avoid overflow.

>> Signed-off-by: Wanpeng Li <liwp.li...@gmail.com>
>> ---
>>   include/linux/vmstat.h |    2 +-
>>   mm/memcontrol.c        |    5 ++---
>>   2 files changed, 3 insertions(+), 4 deletions(-)

>> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
>> index 65efb92..6a14291 100644
>> --- a/include/linux/vmstat.h
>> +++ b/include/linux/vmstat.h
>> @@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
>>        return x;
>>   }

>> -static inline unsigned long zone_page_state(struct zone *zone,
>> +static inline u64 zone_page_state(struct zone *zone,
>>                                        enum zone_stat_item item)
>>   {
>>        long x = atomic_long_read(&zone->vm_stat[item]);

> We established that there is no known reason to use ulong for page
> counters and that IF YOU HAD ONE, you should obviously say so and then
> do a wholesale conversion.  But I don't think you have one.

> This patch makes absolutely no sense.

>>>V2 -> V1:
>>>* fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'

>>>From: Wanpeng Li <l...@linux.vnet.ibm.com>

>>>Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>>>mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>>>value of funtions by u64 to avoid overflow.

>>>Signed-off-by: Wanpeng Li <liwp.li...@gmail.com>
>>>---
>>>  include/linux/vmstat.h |    2 +-
>>>  mm/memcontrol.c        |    5 ++---
>>>  2 files changed, 3 insertions(+), 4 deletions(-)

>>>diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
>>>index 65efb92..6a14291 100644
>>>--- a/include/linux/vmstat.h
>>>+++ b/include/linux/vmstat.h
>>>@@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
>>>    return x;
>>>  }

>>>-static inline unsigned long zone_page_state(struct zone *zone,
>>>+static inline u64 zone_page_state(struct zone *zone,
>>>                                    enum zone_stat_item item)
>>>  {
>>>    long x = atomic_long_read(&zone->vm_stat[item]);

>>We established that there is no known reason to use ulong for page
>>counters and that IF YOU HAD ONE, you should obviously say so and then
>>do a wholesale conversion.  But I don't think you have one.

>>This patch makes absolutely no sense.

>I agree. Then, Nack from me.

>Thanks,
>-Kame

> >>>> V2 -> V1:
> >>>> * fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'

> >>>> From: Wanpeng Li <l...@linux.vnet.ibm.com>

> >>>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
> >>>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
> >>>> value of funtions by u64 to avoid overflow.

> >>>> Signed-off-by: Wanpeng Li <liwp.li...@gmail.com>
> >>>> ---
> >>>>  include/linux/vmstat.h |    2 +-
> >>>>  mm/memcontrol.c        |    5 ++---
> >>>>  2 files changed, 3 insertions(+), 4 deletions(-)

> >>>> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> >>>> index 65efb92..6a14291 100644
> >>>> --- a/include/linux/vmstat.h
> >>>> +++ b/include/linux/vmstat.h
> >>>> @@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
> >>>>   return x;
> >>>>  }

> >>>> -static inline unsigned long zone_page_state(struct zone *zone,
> >>>> +static inline u64 zone_page_state(struct zone *zone,
> >>>>                                   enum zone_stat_item item)
> >>>>  {
> >>>>   long x = atomic_long_read(&zone->vm_stat[item]);

> >>> We established that there is no known reason to use ulong for page
> >>> counters and that IF YOU HAD ONE, you should obviously say so and then
> >>> do a wholesale conversion.  But I don't think you have one.

> >>> This patch makes absolutely no sense.

> >> I agree. Then, Nack from me.

> >> Thanks,
> >> -Kame

> > static unsigned long
> > mem_cgroup_node_nr_lru_pages(struct mem_cgroup *memcg,
> >                       int nid, unsigned int lru_mask)
> > {
> >       u64 total = 0;
> >       int zid;

> >       for (zid = 0; zid < MAX_NR_ZONES; zid++)
> >               total += mem_cgroup_zone_nr_lru_pages(memcg,
> >                                           nid, zid, lru_mask);

> >       return total;
> > }

> > Since you use unsigned long to caculate nr_pages and unsigned long long
> > to caculate bytes, so u64 in function mem_cgroup_node_nr_lru_pages should
> > replace by unsigned long to save kernel stack, right?

> How many bytes do you intend to save by replacing "u64" with "unsigned
> long" ? Have you asked yourself this question ?

>>>>>> V2 -> V1:
>>>>>> * fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'

>>>>>> From: Wanpeng Li <l...@linux.vnet.ibm.com>

>>>>>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>>>>>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>>>>>> value of funtions by u64 to avoid overflow.

>>>>>> Signed-off-by: Wanpeng Li <liwp.li...@gmail.com>
>>>>>> ---
>>>>>>  include/linux/vmstat.h |    2 +-
>>>>>>  mm/memcontrol.c        |    5 ++---
>>>>>>  2 files changed, 3 insertions(+), 4 deletions(-)

>>>>>> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
>>>>>> index 65efb92..6a14291 100644
>>>>>> --- a/include/linux/vmstat.h
>>>>>> +++ b/include/linux/vmstat.h
>>>>>> @@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
>>>>>>        return x;
>>>>>>  }

>>>>>> -static inline unsigned long zone_page_state(struct zone *zone,
>>>>>> +static inline u64 zone_page_state(struct zone *zone,
>>>>>>                                        enum zone_stat_item item)
>>>>>>  {
>>>>>>        long x = atomic_long_read(&zone->vm_stat[item]);

>>>>> We established that there is no known reason to use ulong for page
>>>>> counters and that IF YOU HAD ONE, you should obviously say so and then
>>>>> do a wholesale conversion.  But I don't think you have one.

>>>>> This patch makes absolutely no sense.

>>>> I agree. Then, Nack from me.

>>>> Thanks,
>>>> -Kame

>>> static unsigned long
>>> mem_cgroup_node_nr_lru_pages(struct mem_cgroup *memcg,
>>>                    int nid, unsigned int lru_mask)
>>> {
>>>    u64 total = 0;
>>>    int zid;

>>>    for (zid = 0; zid < MAX_NR_ZONES; zid++)
>>>            total += mem_cgroup_zone_nr_lru_pages(memcg,
>>>                                        nid, zid, lru_mask);

>>>    return total;
>>> }

>>> Since you use unsigned long to caculate nr_pages and unsigned long long
>>> to caculate bytes, so u64 in function mem_cgroup_node_nr_lru_pages should
>>> replace by unsigned long to save kernel stack, right?

>> How many bytes do you intend to save by replacing "u64" with "unsigned
>> long" ? Have you asked yourself this question ?

> I think fixing these types is a good thing.  Not for their memory
> savings but to clarify the code.  Otherwise, people will scratch their
> heads and waste time over whether there is something that requires the
> counter to be 64-bit on a 32-bit system when really there isn't.