Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1482294 > unrolled thread

[RFC] mm: Change the data type of huge page size from unsigned long to u64

Started byRui Teng <rui.teng@linux.vnet.ibm.com>
First post2016-09-13 11:30 +0200
Last post2016-09-13 15:10 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [RFC] mm: Change the data type of huge page size from unsigned long to u64 Rui Teng <rui.teng@linux.vnet.ibm.com> - 2016-09-13 11:30 +0200
    Re: [RFC] mm: Change the data type of huge page size from unsigned  long to u64 "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-09-13 11:40 +0200
      Re: [RFC] mm: Change the data type of huge page size from unsigned  long to u64 Rui Teng <rui.teng@linux.vnet.ibm.com> - 2016-09-13 13:30 +0200
        Re: [RFC] mm: Change the data type of huge page size from unsigned  long to u64 "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-09-13 13:50 +0200
          Re: [RFC] mm: Change the data type of huge page size from unsigned  long to u64 Rui Teng <rui.teng@linux.vnet.ibm.com> - 2016-09-13 15:10 +0200

#1482294 — [RFC] mm: Change the data type of huge page size from unsigned long to u64

FromRui Teng <rui.teng@linux.vnet.ibm.com>
Date2016-09-13 11:30 +0200
Subject[RFC] mm: Change the data type of huge page size from unsigned long to u64
Message-ID<sgScp-8ns-3@gated-at.bofh.it>
The huge page size could be 16G(0x400000000) on ppc64 architecture, and it will
cause an overflow on unsigned long data type(0xFFFFFFFF).

For example, huge_page_size() will return 0, if the PAGE_SIZE is 65536 and
h->order is 18, which is the result on ppc64 with 16G huge page enabled.

I think it needs to change the data type from unsigned long to u64. But it will
cause a lot of functions and data structures changed. Any comments and
suggestions?

Thanks!

Signed-off-by: Rui Teng <rui.teng@linux.vnet.ibm.com>
---
 include/linux/hugetlb.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index c26d463..efbe5cf 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -374,9 +374,9 @@ static inline struct hstate *hstate_vma(struct vm_area_struct *vma)
 	return hstate_file(vma->vm_file);
 }
 
-static inline unsigned long huge_page_size(struct hstate *h)
+static inline u64 huge_page_size(struct hstate *h)
 {
-	return (unsigned long)PAGE_SIZE << h->order;
+	return (u64)PAGE_SIZE << h->order;
 }
 
 extern unsigned long vma_kernel_pagesize(struct vm_area_struct *vma);
-- 
2.7.4

[toc] | [next] | [standalone]


#1482301 — Re: [RFC] mm: Change the data type of huge page size from unsigned long to u64

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2016-09-13 11:40 +0200
SubjectRe: [RFC] mm: Change the data type of huge page size from unsigned long to u64
Message-ID<sgSm5-8r1-7@gated-at.bofh.it>
In reply to#1482294
On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
> The huge page size could be 16G(0x400000000) on ppc64 architecture, and it will
> cause an overflow on unsigned long data type(0xFFFFFFFF).

Huh? ppc64 is 64-bit system and sizeof(void *) is equal to
sizeof(unsigned long) on Linux (LP64 model).

So where your 0xFFFFFFFF comes from?

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]


#1482382 — Re: [RFC] mm: Change the data type of huge page size from unsigned long to u64

FromRui Teng <rui.teng@linux.vnet.ibm.com>
Date2016-09-13 13:30 +0200
SubjectRe: [RFC] mm: Change the data type of huge page size from unsigned long to u64
Message-ID<sgU4x-18N-13@gated-at.bofh.it>
In reply to#1482301
On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
> On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
>> The huge page size could be 16G(0x400000000) on ppc64 architecture, and it will
>> cause an overflow on unsigned long data type(0xFFFFFFFF).
>
> Huh? ppc64 is 64-bit system and sizeof(void *) is equal to
> sizeof(unsigned long) on Linux (LP64 model).
>
> So where your 0xFFFFFFFF comes from?
>
The size of unsigned long data type is 4 bytes, and the 0xFFFFFFFF here
is the maximum value. And 16G is bigger than it.

[toc] | [prev] | [next] | [standalone]


#1482391 — Re: [RFC] mm: Change the data type of huge page size from unsigned long to u64

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2016-09-13 13:50 +0200
SubjectRe: [RFC] mm: Change the data type of huge page size from unsigned long to u64
Message-ID<sgUnU-1gb-19@gated-at.bofh.it>
In reply to#1482382
On Tue, Sep 13, 2016 at 07:21:07PM +0800, Rui Teng wrote:
> On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
> >On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
> >>The huge page size could be 16G(0x400000000) on ppc64 architecture, and it will
> >>cause an overflow on unsigned long data type(0xFFFFFFFF).
> >
> >Huh? ppc64 is 64-bit system and sizeof(void *) is equal to
> >sizeof(unsigned long) on Linux (LP64 model).
> >
> >So where your 0xFFFFFFFF comes from?
> >
> The size of unsigned long data type is 4 bytes

No, it's not.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]


#1482450 — Re: [RFC] mm: Change the data type of huge page size from unsigned long to u64

FromRui Teng <rui.teng@linux.vnet.ibm.com>
Date2016-09-13 15:10 +0200
SubjectRe: [RFC] mm: Change the data type of huge page size from unsigned long to u64
Message-ID<sgVDj-2n0-23@gated-at.bofh.it>
In reply to#1482391
On 9/13/16 7:40 PM, Kirill A. Shutemov wrote:
> On Tue, Sep 13, 2016 at 07:21:07PM +0800, Rui Teng wrote:
>> On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
>>> On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
>>>> The huge page size could be 16G(0x400000000) on ppc64 architecture, and it will
>>>> cause an overflow on unsigned long data type(0xFFFFFFFF).
>>>
>>> Huh? ppc64 is 64-bit system and sizeof(void *) is equal to
>>> sizeof(unsigned long) on Linux (LP64 model).
>>>
>>> So where your 0xFFFFFFFF comes from?
>>>
>> The size of unsigned long data type is 4 bytes
>
> No, it's not.
>
Sorry, my fault!
I print the unsigned long with "%ul" instead of "%lu" and got the wrong
result. Sorry!

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web