[PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

When SPARSEMEM is used, there is an indication that pageblock is not
allowed to exceed one mem_section. Current code doesn't have this
constrain explicitly.

This patch adds this to make sure it won't.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
---
 include/linux/mmzone.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index be126113b499..8f3ce3a0c7d6 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1084,6 +1084,10 @@ static inline unsigned long early_pfn_to_nid(unsigned long pfn)
 #error Allocator MAX_ORDER exceeds SECTION_SIZE
 #endif
 
+#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
+#error Allocator pageblock_order exceeds SECTION_SIZE
+#endif
+
 static inline unsigned long pfn_to_section_nr(unsigned long pfn)
 {
 	return pfn >> PFN_SECTION_SHIFT;
-- 
2.15.1

[PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set

[Wei Yang]

Two cleanups in this patch:

  * since pageblock_nr_pages == (1 << pageblock_order), the roundup()
    and right shift pageblock_order could be replaced with
    DIV_ROUND_UP()
  * use BITS_TO_LONGS() to get number of bytes for bitmap

This patch also fix one typo in comment.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
---
 mm/page_alloc.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7c745c305332..baf473f80800 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6204,7 +6204,7 @@ static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
 /*
  * Calculate the size of the zone->blockflags rounded to an unsigned long
  * Start by making sure zonesize is a multiple of pageblock_order by rounding
- * up. Then use 1 NR_PAGEBLOCK_BITS worth of bits per pageblock, finally
+ * up. Then use 1 NR_PAGEBLOCK_BITS width of bits per pageblock, finally
  * round what is now in bits to nearest long in bits, then return it in
  * bytes.
  */
@@ -6213,12 +6213,9 @@ static unsigned long __init usemap_size(unsigned long zone_start_pfn, unsigned l
 	unsigned long usemapsize;
 
 	zonesize += zone_start_pfn & (pageblock_nr_pages-1);
-	usemapsize = roundup(zonesize, pageblock_nr_pages);
-	usemapsize = usemapsize >> pageblock_order;
+	usemapsize = DIV_ROUND_UP(zonesize, pageblock_nr_pages);
 	usemapsize *= NR_PAGEBLOCK_BITS;
-	usemapsize = roundup(usemapsize, 8 * sizeof(unsigned long));
-
-	return usemapsize / 8;
+	return BITS_TO_LONGS(usemapsize) * sizeof(unsigned long);
 }
 
 static void __ref setup_usemap(struct pglist_data *pgdat,
-- 
2.15.1

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Mel Gorman]

On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
> When SPARSEMEM is used, there is an indication that pageblock is not
> allowed to exceed one mem_section. Current code doesn't have this
> constrain explicitly.
> 
> This patch adds this to make sure it won't.
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>

Is this even possible? This would imply that the section size is smaller
than max order which would be quite a crazy selection for a sparesemem
section size. A lot of assumptions on the validity of PFNs within a
max-order boundary would be broken with such a section size. I'd be
surprised if such a setup could even boot, let alone run.

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
>On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
>> When SPARSEMEM is used, there is an indication that pageblock is not
>> allowed to exceed one mem_section. Current code doesn't have this
>> constrain explicitly.
>> 
>> This patch adds this to make sure it won't.
>> 
>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>
>Is this even possible? This would imply that the section size is smaller
>than max order which would be quite a crazy selection for a sparesemem
>section size. A lot of assumptions on the validity of PFNs within a
>max-order boundary would be broken with such a section size. I'd be
>surprised if such a setup could even boot, let alone run.

pageblock_order has two definitions.

    #define pageblock_order        HUGETLB_PAGE_ORDER

    #define pageblock_order        (MAX_ORDER-1)

If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
MAX_ORDER, which ensures it is smaller than section size.

If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
section size. Maybe I missed it?

>
>-- 
>Mel Gorman
>SUSE Labs

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Mel Gorman]

On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote:
> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
> >On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
> >> When SPARSEMEM is used, there is an indication that pageblock is not
> >> allowed to exceed one mem_section. Current code doesn't have this
> >> constrain explicitly.
> >> 
> >> This patch adds this to make sure it won't.
> >> 
> >> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> >
> >Is this even possible? This would imply that the section size is smaller
> >than max order which would be quite a crazy selection for a sparesemem
> >section size. A lot of assumptions on the validity of PFNs within a
> >max-order boundary would be broken with such a section size. I'd be
> >surprised if such a setup could even boot, let alone run.
> 
> pageblock_order has two definitions.
> 
>     #define pageblock_order        HUGETLB_PAGE_ORDER
> 
>     #define pageblock_order        (MAX_ORDER-1)
> 
> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
> MAX_ORDER, which ensures it is smaller than section size.
> 
> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
> section size. Maybe I missed it?
> 

HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge
pages (not gigantic) pages are served from the buddy allocator which is
limited by MAX_ORDER.

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote:
>On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote:
>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
>> >On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
>> >> When SPARSEMEM is used, there is an indication that pageblock is not
>> >> allowed to exceed one mem_section. Current code doesn't have this
>> >> constrain explicitly.
>> >> 
>> >> This patch adds this to make sure it won't.
>> >> 
>> >> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>> >
>> >Is this even possible? This would imply that the section size is smaller
>> >than max order which would be quite a crazy selection for a sparesemem
>> >section size. A lot of assumptions on the validity of PFNs within a
>> >max-order boundary would be broken with such a section size. I'd be
>> >surprised if such a setup could even boot, let alone run.
>> 
>> pageblock_order has two definitions.
>> 
>>     #define pageblock_order        HUGETLB_PAGE_ORDER
>> 
>>     #define pageblock_order        (MAX_ORDER-1)
>> 
>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
>> MAX_ORDER, which ensures it is smaller than section size.
>> 
>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
>> section size. Maybe I missed it?
>> 
>
>HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge
>pages (not gigantic) pages are served from the buddy allocator which is
>limited by MAX_ORDER.
>

Maybe I am lost here, I got one possible definition on x86.

#define pageblock_order		HUGETLB_PAGE_ORDER
#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
#define HPAGE_SHIFT		PMD_SHIFT
#define PMD_SHIFT	PUD_SHIFT
#define PUD_SHIFT	30

This leads to pageblock_order = (30 - 12) = 18 > MAX_ORDER  ?

What you mentioned sounds reasonable. A huge page should be less than
MAX_ORDER, otherwise page allocator couldn't handle it. But I don't see
the connection between MAX_ORDER and HUGETLB_PAGE_ORDER. Do we need to
add a check on this? Or it already has similar contrain in code, but I
missed it?

>-- 
>Mel Gorman
>SUSE Labs

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[David Hildenbrand]

On 05.12.18 23:31, Wei Yang wrote:
> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote:
>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote:
>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
>>>>> When SPARSEMEM is used, there is an indication that pageblock is not
>>>>> allowed to exceed one mem_section. Current code doesn't have this
>>>>> constrain explicitly.
>>>>>
>>>>> This patch adds this to make sure it won't.
>>>>>
>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>>>
>>>> Is this even possible? This would imply that the section size is smaller
>>>> than max order which would be quite a crazy selection for a sparesemem
>>>> section size. A lot of assumptions on the validity of PFNs within a
>>>> max-order boundary would be broken with such a section size. I'd be
>>>> surprised if such a setup could even boot, let alone run.
>>>
>>> pageblock_order has two definitions.
>>>
>>>     #define pageblock_order        HUGETLB_PAGE_ORDER
>>>
>>>     #define pageblock_order        (MAX_ORDER-1)
>>>
>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
>>> MAX_ORDER, which ensures it is smaller than section size.
>>>
>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
>>> section size. Maybe I missed it?
>>>
>>
>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge
>> pages (not gigantic) pages are served from the buddy allocator which is
>> limited by MAX_ORDER.
>>
> 
> Maybe I am lost here, I got one possible definition on x86.
> 
> #define pageblock_order		HUGETLB_PAGE_ORDER
> #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> #define HPAGE_SHIFT		PMD_SHIFT
> #define PMD_SHIFT	PUD_SHIFT

PMD_SHIFT is usually 21

arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT   21
arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT       21

Unless CONFIG_PGTABLE_LEVELS <= 2

Then include/asm-generic/pgtable-nopmd.h will be used in
arch/x86/include/asm/pgtable_types.h
	#define PMD_SHIFT	PUD_SHIFT

In that case, also include/asm-generic/pgtable-nopmd.h is uses
	#define PUD_SHIFT	P4D_SHIFT

... include/asm-generic/pgtable-nop4d.h
	#define P4D_SHIFT	PGDIR_SHIFT


And that would be
arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22

If I am not wrong.

So we would have pageblock_order = (22 - 12) = 10


> #define PUD_SHIFT	30
> 
> This leads to pageblock_order = (30 - 12) = 18 > MAX_ORDER  ?
> 
> What you mentioned sounds reasonable. A huge page should be less than
> MAX_ORDER, otherwise page allocator couldn't handle it. But I don't see
> the connection between MAX_ORDER and HUGETLB_PAGE_ORDER. Do we need to
> add a check on this? Or it already has similar contrain in code, but I
> missed it?
> 
>> -- 
>> Mel Gorman
>> SUSE Labs
> 


-- 

Thanks,

David / dhildenb

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Thu, Dec 06, 2018 at 10:00:05AM +0100, David Hildenbrand wrote:
>On 05.12.18 23:31, Wei Yang wrote:
>> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote:
>>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote:
>>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
>>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
>>>>>> When SPARSEMEM is used, there is an indication that pageblock is not
>>>>>> allowed to exceed one mem_section. Current code doesn't have this
>>>>>> constrain explicitly.
>>>>>>
>>>>>> This patch adds this to make sure it won't.
>>>>>>
>>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>>>>
>>>>> Is this even possible? This would imply that the section size is smaller
>>>>> than max order which would be quite a crazy selection for a sparesemem
>>>>> section size. A lot of assumptions on the validity of PFNs within a
>>>>> max-order boundary would be broken with such a section size. I'd be
>>>>> surprised if such a setup could even boot, let alone run.
>>>>
>>>> pageblock_order has two definitions.
>>>>
>>>>     #define pageblock_order        HUGETLB_PAGE_ORDER
>>>>
>>>>     #define pageblock_order        (MAX_ORDER-1)
>>>>
>>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
>>>> MAX_ORDER, which ensures it is smaller than section size.
>>>>
>>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
>>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
>>>> section size. Maybe I missed it?
>>>>
>>>
>>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge
>>> pages (not gigantic) pages are served from the buddy allocator which is
>>> limited by MAX_ORDER.
>>>
>> 
>> Maybe I am lost here, I got one possible definition on x86.
>> 
>> #define pageblock_order		HUGETLB_PAGE_ORDER
>> #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>> #define HPAGE_SHIFT		PMD_SHIFT
>> #define PMD_SHIFT	PUD_SHIFT
>
>PMD_SHIFT is usually 21
>
>arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT   21
>arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT       21
>
>Unless CONFIG_PGTABLE_LEVELS <= 2
>
>Then include/asm-generic/pgtable-nopmd.h will be used in
>arch/x86/include/asm/pgtable_types.h
>	#define PMD_SHIFT	PUD_SHIFT
>
>In that case, also include/asm-generic/pgtable-nopmd.h is uses
>	#define PUD_SHIFT	P4D_SHIFT
>
>... include/asm-generic/pgtable-nop4d.h
>	#define P4D_SHIFT	PGDIR_SHIFT
>
>
>And that would be
>arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22
>
>If I am not wrong.
>
>So we would have pageblock_order = (22 - 12) = 10
>

Thank, David :-)

I think current configuration is correct, while all these digits are
written by programmer.

My concern and suggestion is to add a compiler check to enforce this. So
that we would avoid this situation if someone miss this constrain. Just
as the check on MAX_ORDER and SECION_SIZE.

>
>> #define PUD_SHIFT	30
>> 
>> This leads to pageblock_order = (30 - 12) = 18 > MAX_ORDER  ?
>> 
>> What you mentioned sounds reasonable. A huge page should be less than
>> MAX_ORDER, otherwise page allocator couldn't handle it. But I don't see
>> the connection between MAX_ORDER and HUGETLB_PAGE_ORDER. Do we need to
>> add a check on this? Or it already has similar contrain in code, but I
>> missed it?
>> 
>>> -- 
>>> Mel Gorman
>>> SUSE Labs
>> 
>
>
>-- 
>
>Thanks,
>
>David / dhildenb

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[David Hildenbrand]

On 06.12.18 10:21, Wei Yang wrote:
> On Thu, Dec 06, 2018 at 10:00:05AM +0100, David Hildenbrand wrote:
>> On 05.12.18 23:31, Wei Yang wrote:
>>> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote:
>>>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote:
>>>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
>>>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
>>>>>>> When SPARSEMEM is used, there is an indication that pageblock is not
>>>>>>> allowed to exceed one mem_section. Current code doesn't have this
>>>>>>> constrain explicitly.
>>>>>>>
>>>>>>> This patch adds this to make sure it won't.
>>>>>>>
>>>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>>>>>
>>>>>> Is this even possible? This would imply that the section size is smaller
>>>>>> than max order which would be quite a crazy selection for a sparesemem
>>>>>> section size. A lot of assumptions on the validity of PFNs within a
>>>>>> max-order boundary would be broken with such a section size. I'd be
>>>>>> surprised if such a setup could even boot, let alone run.
>>>>>
>>>>> pageblock_order has two definitions.
>>>>>
>>>>>     #define pageblock_order        HUGETLB_PAGE_ORDER
>>>>>
>>>>>     #define pageblock_order        (MAX_ORDER-1)
>>>>>
>>>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
>>>>> MAX_ORDER, which ensures it is smaller than section size.
>>>>>
>>>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
>>>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
>>>>> section size. Maybe I missed it?
>>>>>
>>>>
>>>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge
>>>> pages (not gigantic) pages are served from the buddy allocator which is
>>>> limited by MAX_ORDER.
>>>>
>>>
>>> Maybe I am lost here, I got one possible definition on x86.
>>>
>>> #define pageblock_order		HUGETLB_PAGE_ORDER
>>> #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>>> #define HPAGE_SHIFT		PMD_SHIFT
>>> #define PMD_SHIFT	PUD_SHIFT
>>
>> PMD_SHIFT is usually 21
>>
>> arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT   21
>> arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT       21
>>
>> Unless CONFIG_PGTABLE_LEVELS <= 2
>>
>> Then include/asm-generic/pgtable-nopmd.h will be used in
>> arch/x86/include/asm/pgtable_types.h
>> 	#define PMD_SHIFT	PUD_SHIFT
>>
>> In that case, also include/asm-generic/pgtable-nopmd.h is uses
>> 	#define PUD_SHIFT	P4D_SHIFT
>>
>> ... include/asm-generic/pgtable-nop4d.h
>> 	#define P4D_SHIFT	PGDIR_SHIFT
>>
>>
>> And that would be
>> arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22
>>
>> If I am not wrong.
>>
>> So we would have pageblock_order = (22 - 12) = 10
>>
> 
> Thank, David :-)
> 
> I think current configuration is correct, while all these digits are
> written by programmer.
> 
> My concern and suggestion is to add a compiler check to enforce this. So
> that we would avoid this situation if someone miss this constrain. Just
> as the check on MAX_ORDER and SECION_SIZE.

I am not completely against this, I rather wonder if it is needed
because I assume other things will break horribly in case this is
violated. And at that would only be helpful for somebody developing for
a new architecture/flavor.

As I am a friend of documenting things that are not obvious, I would
rather suggest to add a comment to the
	#define pageblock_order		HUGETLB_PAGE_ORDER
line, stating what we just learned.

/*
 * HUGETLB_PAGE_ORDER will always be smaller than MAX_ORDER, so that
 * huge (not gigantic) pages can be served from the buddy allocator.
 */


-- 

Thanks,

David / dhildenb

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Thu, Dec 06, 2018 at 10:26:55AM +0100, David Hildenbrand wrote:
>On 06.12.18 10:21, Wei Yang wrote:
>> On Thu, Dec 06, 2018 at 10:00:05AM +0100, David Hildenbrand wrote:
>>> On 05.12.18 23:31, Wei Yang wrote:
>>>> On Wed, Dec 05, 2018 at 03:37:33PM +0000, Mel Gorman wrote:
>>>>> On Wed, Dec 05, 2018 at 12:08:20PM +0000, Wei Yang wrote:
>>>>>> On Wed, Dec 05, 2018 at 11:15:13AM +0000, Mel Gorman wrote:
>>>>>>> On Wed, Dec 05, 2018 at 05:19:04PM +0800, Wei Yang wrote:
>>>>>>>> When SPARSEMEM is used, there is an indication that pageblock is not
>>>>>>>> allowed to exceed one mem_section. Current code doesn't have this
>>>>>>>> constrain explicitly.
>>>>>>>>
>>>>>>>> This patch adds this to make sure it won't.
>>>>>>>>
>>>>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>>>>>>
>>>>>>> Is this even possible? This would imply that the section size is smaller
>>>>>>> than max order which would be quite a crazy selection for a sparesemem
>>>>>>> section size. A lot of assumptions on the validity of PFNs within a
>>>>>>> max-order boundary would be broken with such a section size. I'd be
>>>>>>> surprised if such a setup could even boot, let alone run.
>>>>>>
>>>>>> pageblock_order has two definitions.
>>>>>>
>>>>>>     #define pageblock_order        HUGETLB_PAGE_ORDER
>>>>>>
>>>>>>     #define pageblock_order        (MAX_ORDER-1)
>>>>>>
>>>>>> If CONFIG_HUGETLB_PAGE is not enabled, pageblock_order is related to
>>>>>> MAX_ORDER, which ensures it is smaller than section size.
>>>>>>
>>>>>> If CONFIG_HUGETLB_PAGE is enabled, pageblock_order is not related to
>>>>>> MAX_ORDER. I don't see HUGETLB_PAGE_ORDER is ensured to be less than
>>>>>> section size. Maybe I missed it?
>>>>>>
>>>>>
>>>>> HUGETLB_PAGE_ORDER is less than MAX_ORDER on the basis that normal huge
>>>>> pages (not gigantic) pages are served from the buddy allocator which is
>>>>> limited by MAX_ORDER.
>>>>>
>>>>
>>>> Maybe I am lost here, I got one possible definition on x86.
>>>>
>>>> #define pageblock_order		HUGETLB_PAGE_ORDER
>>>> #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>>>> #define HPAGE_SHIFT		PMD_SHIFT
>>>> #define PMD_SHIFT	PUD_SHIFT
>>>
>>> PMD_SHIFT is usually 21
>>>
>>> arch/x86/include/asm/pgtable-3level_types.h:#define PMD_SHIFT   21
>>> arch/x86/include/asm/pgtable_64_types.h:#define PMD_SHIFT       21
>>>
>>> Unless CONFIG_PGTABLE_LEVELS <= 2
>>>
>>> Then include/asm-generic/pgtable-nopmd.h will be used in
>>> arch/x86/include/asm/pgtable_types.h
>>> 	#define PMD_SHIFT	PUD_SHIFT
>>>
>>> In that case, also include/asm-generic/pgtable-nopmd.h is uses
>>> 	#define PUD_SHIFT	P4D_SHIFT
>>>
>>> ... include/asm-generic/pgtable-nop4d.h
>>> 	#define P4D_SHIFT	PGDIR_SHIFT
>>>
>>>
>>> And that would be
>>> arch/x86/include/asm/pgtable-2level_types.h:#define PGDIR_SHIFT 22
>>>
>>> If I am not wrong.
>>>
>>> So we would have pageblock_order = (22 - 12) = 10
>>>
>> 
>> Thank, David :-)
>> 
>> I think current configuration is correct, while all these digits are
>> written by programmer.
>> 
>> My concern and suggestion is to add a compiler check to enforce this. So
>> that we would avoid this situation if someone miss this constrain. Just
>> as the check on MAX_ORDER and SECION_SIZE.
>
>I am not completely against this, I rather wonder if it is needed
>because I assume other things will break horribly in case this is
>violated. And at that would only be helpful for somebody developing for
>a new architecture/flavor.

I think you are right.

>
>As I am a friend of documenting things that are not obvious, I would
>rather suggest to add a comment to the
>	#define pageblock_order		HUGETLB_PAGE_ORDER
>line, stating what we just learned.
>
>/*
> * HUGETLB_PAGE_ORDER will always be smaller than MAX_ORDER, so that
> * huge (not gigantic) pages can be served from the buddy allocator.
> */
>

This looks good to me. Let's see which one others prefer :-)

>
>-- 
>
>Thanks,
>
>David / dhildenb

-- 
Wei Yang
Help you, Help me

Re: [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set

[Wei Yang]

On Wed, Dec 05, 2018 at 05:19:05PM +0800, Wei Yang wrote:
>Two cleanups in this patch:
>
>  * since pageblock_nr_pages == (1 << pageblock_order), the roundup()
>    and right shift pageblock_order could be replaced with
>    DIV_ROUND_UP()
>  * use BITS_TO_LONGS() to get number of bytes for bitmap
>
>This patch also fix one typo in comment.

Patch 1 maybe controversial, how about this one :-)

Look forward some comments.

>
>Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>---
> mm/page_alloc.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
>diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>index 7c745c305332..baf473f80800 100644
>--- a/mm/page_alloc.c
>+++ b/mm/page_alloc.c
>@@ -6204,7 +6204,7 @@ static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
> /*
>  * Calculate the size of the zone->blockflags rounded to an unsigned long
>  * Start by making sure zonesize is a multiple of pageblock_order by rounding
>- * up. Then use 1 NR_PAGEBLOCK_BITS worth of bits per pageblock, finally
>+ * up. Then use 1 NR_PAGEBLOCK_BITS width of bits per pageblock, finally
>  * round what is now in bits to nearest long in bits, then return it in
>  * bytes.
>  */
>@@ -6213,12 +6213,9 @@ static unsigned long __init usemap_size(unsigned long zone_start_pfn, unsigned l
> 	unsigned long usemapsize;
> 
> 	zonesize += zone_start_pfn & (pageblock_nr_pages-1);
>-	usemapsize = roundup(zonesize, pageblock_nr_pages);
>-	usemapsize = usemapsize >> pageblock_order;
>+	usemapsize = DIV_ROUND_UP(zonesize, pageblock_nr_pages);
> 	usemapsize *= NR_PAGEBLOCK_BITS;
>-	usemapsize = roundup(usemapsize, 8 * sizeof(unsigned long));
>-
>-	return usemapsize / 8;
>+	return BITS_TO_LONGS(usemapsize) * sizeof(unsigned long);
> }
> 
> static void __ref setup_usemap(struct pglist_data *pgdat,
>-- 
>2.15.1

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

Hi Wei,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.2.0 make.cross ARCH=powerpc 

All warnings (new ones prefixed by >>):

   In file included from include/linux/gfp.h:6:0,
                    from include/linux/xarray.h:14,
                    from include/linux/radix-tree.h:31,
                    from include/linux/fs.h:15,
                    from include/linux/compat.h:17,
                    from arch/powerpc/kernel/asm-offsets.c:16:
>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
         ^~~~~~~~~~~~~~~
--
   In file included from include/linux/gfp.h:6:0,
                    from include/linux/mm.h:10,
                    from mm//swap.c:16:
>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
         ^~~~~~~~~~~~~~~
   In file included from include/linux/gfp.h:6:0,
                    from include/linux/mm.h:10,
                    from mm//swap.c:16:
>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
         ^~~~~~~~~~~~~~~

vim +/pageblock_order +1088 include/linux/mmzone.h

  1087	
> 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
  1089	#error Allocator pageblock_order exceeds SECTION_SIZE
  1090	#endif
  1091	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59400 bytes --]

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote:
>Hi Wei,
>
>Thank you for the patch! Perhaps something to improve:
>
>[auto build test WARNING on linus/master]
>[also build test WARNING on v4.20-rc5 next-20181207]
>[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
>url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
>config: powerpc-allmodconfig (attached as .config)
>compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>reproduce:
>        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>        chmod +x ~/bin/make.cross
>        # save the attached .config to linux build tree
>        GCC_VERSION=7.2.0 make.cross ARCH=powerpc 
>
>All warnings (new ones prefixed by >>):
>
>   In file included from include/linux/gfp.h:6:0,
>                    from include/linux/xarray.h:14,
>                    from include/linux/radix-tree.h:31,
>                    from include/linux/fs.h:15,
>                    from include/linux/compat.h:17,
>                    from arch/powerpc/kernel/asm-offsets.c:16:
>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>         ^~~~~~~~~~~~~~~
>--
>   In file included from include/linux/gfp.h:6:0,
>                    from include/linux/mm.h:10,
>                    from mm//swap.c:16:
>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>         ^~~~~~~~~~~~~~~
>   In file included from include/linux/gfp.h:6:0,
>                    from include/linux/mm.h:10,
>                    from mm//swap.c:16:
>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>         ^~~~~~~~~~~~~~~
>
>vim +/pageblock_order +1088 include/linux/mmzone.h
>
>  1087	
>> 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>  1089	#error Allocator pageblock_order exceeds SECTION_SIZE
>  1090	#endif
>  1091	
>

I took a look at the latest code, at line 1082 of the same file uses
pageblock_order. And I apply this patch on top of v4.20-rc5, the build
looks good to me.

Confused why this introduce an compile error.

>---
>0-DAY kernel test infrastructure                Open Source Technology Center
>https://lists.01.org/pipermail/kbuild-all                   Intel Corporation



-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

Hi Wei,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.2.0 make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   In file included from include/linux/gfp.h:6:0,
                    from include/linux/umh.h:4,
                    from include/linux/kmod.h:22,
                    from include/linux/module.h:13,
                    from drivers/misc/ocxl/main.c:3:
>> include/linux/mmzone.h:1088:6: error: "pageblock_order" is not defined, evaluates to 0 [-Werror=undef]
    #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
         ^~~~~~~~~~~~~~~
   cc1: all warnings being treated as errors

vim +/pageblock_order +1088 include/linux/mmzone.h

  1087	
> 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
  1089	#error Allocator pageblock_order exceeds SECTION_SIZE
  1090	#endif
  1091	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24077 bytes --]

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Rong Chen]

On 12/09/2018 08:03 PM, Wei Yang wrote:
> On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote:
>> Hi Wei,
>>
>> Thank you for the patch! Perhaps something to improve:
>>
>> [auto build test WARNING on linus/master]
>> [also build test WARNING on v4.20-rc5 next-20181207]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>
>> url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
>> config: powerpc-allmodconfig (attached as .config)
>> compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>         chmod +x ~/bin/make.cross
>>         # save the attached .config to linux build tree
>>         GCC_VERSION=7.2.0 make.cross ARCH=powerpc
>>
>> All warnings (new ones prefixed by >>):
>>
>>    In file included from include/linux/gfp.h:6:0,
>>                     from include/linux/xarray.h:14,
>>                     from include/linux/radix-tree.h:31,
>>                     from include/linux/fs.h:15,
>>                     from include/linux/compat.h:17,
>>                     from arch/powerpc/kernel/asm-offsets.c:16:
>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>>     #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>          ^~~~~~~~~~~~~~~
>> --
>>    In file included from include/linux/gfp.h:6:0,
>>                     from include/linux/mm.h:10,
>>                     from mm//swap.c:16:
>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>>     #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>          ^~~~~~~~~~~~~~~
>>    In file included from include/linux/gfp.h:6:0,
>>                     from include/linux/mm.h:10,
>>                     from mm//swap.c:16:
>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>>     #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>          ^~~~~~~~~~~~~~~
>>
>> vim +/pageblock_order +1088 include/linux/mmzone.h
>>
>>   1087	
>>> 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>   1089	#error Allocator pageblock_order exceeds SECTION_SIZE
>>   1090	#endif
>>   1091	
>>
> I took a look at the latest code, at line 1082 of the same file uses
> pageblock_order. And I apply this patch on top of v4.20-rc5, the build
> looks good to me.
>
> Confused why this introduce an compile error.

Hi Wei,

we could reproduce the warnings with using make.cross.

Best Regards,
Rong Chen

>
>> ---
>> 0-DAY kernel test infrastructure                Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>
>

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote:
>
>
>On 12/09/2018 08:03 PM, Wei Yang wrote:
>> On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote:
>> > Hi Wei,
>> > 
>> > Thank you for the patch! Perhaps something to improve:
>> > 
>> > [auto build test WARNING on linus/master]
>> > [also build test WARNING on v4.20-rc5 next-20181207]
>> > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>> > 
>> > url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
>> > config: powerpc-allmodconfig (attached as .config)
>> > compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> > reproduce:
>> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> >         chmod +x ~/bin/make.cross
>> >         # save the attached .config to linux build tree
>> >         GCC_VERSION=7.2.0 make.cross ARCH=powerpc
>> > 
>> > All warnings (new ones prefixed by >>):
>> > 
>> >    In file included from include/linux/gfp.h:6:0,
>> >                     from include/linux/xarray.h:14,
>> >                     from include/linux/radix-tree.h:31,
>> >                     from include/linux/fs.h:15,
>> >                     from include/linux/compat.h:17,
>> >                     from arch/powerpc/kernel/asm-offsets.c:16:
>> > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>> >     #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> >          ^~~~~~~~~~~~~~~
>> > --
>> >    In file included from include/linux/gfp.h:6:0,
>> >                     from include/linux/mm.h:10,
>> >                     from mm//swap.c:16:
>> > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>> >     #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> >          ^~~~~~~~~~~~~~~
>> >    In file included from include/linux/gfp.h:6:0,
>> >                     from include/linux/mm.h:10,
>> >                     from mm//swap.c:16:
>> > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>> >     #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> >          ^~~~~~~~~~~~~~~
>> > 
>> > vim +/pageblock_order +1088 include/linux/mmzone.h
>> > 
>> >   1087	
>> > > 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> >   1089	#error Allocator pageblock_order exceeds SECTION_SIZE
>> >   1090	#endif
>> >   1091	
>> > 
>> I took a look at the latest code, at line 1082 of the same file uses
>> pageblock_order. And I apply this patch on top of v4.20-rc5, the build
>> looks good to me.
>> 
>> Confused why this introduce an compile error.
>
>Hi Wei,
>
>we could reproduce the warnings with using make.cross.
>

That's interesting.

Do you see this file already use pageblock_order in line 1081?

Is this one report warning?

>Best Regards,
>Rong Chen
>
>> 
>> > ---
>> > 0-DAY kernel test infrastructure                Open Source Technology Center
>> > https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>> 
>> 

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Rong Chen]

[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]



On 12/13/2018 11:08 AM, Wei Yang wrote:
> On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote:
>>
>> On 12/09/2018 08:03 PM, Wei Yang wrote:
>>> On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote:
>>>> Hi Wei,
>>>>
>>>> Thank you for the patch! Perhaps something to improve:
>>>>
>>>> [auto build test WARNING on linus/master]
>>>> [also build test WARNING on v4.20-rc5 next-20181207]
>>>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>>>
>>>> url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
>>>> config: powerpc-allmodconfig (attached as .config)
>>>> compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>>> reproduce:
>>>>          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>>          chmod +x ~/bin/make.cross
>>>>          # save the attached .config to linux build tree
>>>>          GCC_VERSION=7.2.0 make.cross ARCH=powerpc
>>>>
>>>> All warnings (new ones prefixed by >>):
>>>>
>>>>     In file included from include/linux/gfp.h:6:0,
>>>>                      from include/linux/xarray.h:14,
>>>>                      from include/linux/radix-tree.h:31,
>>>>                      from include/linux/fs.h:15,
>>>>                      from include/linux/compat.h:17,
>>>>                      from arch/powerpc/kernel/asm-offsets.c:16:
>>>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>>>>      #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>>>           ^~~~~~~~~~~~~~~
>>>> --
>>>>     In file included from include/linux/gfp.h:6:0,
>>>>                      from include/linux/mm.h:10,
>>>>                      from mm//swap.c:16:
>>>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>>>>      #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>>>           ^~~~~~~~~~~~~~~
>>>>     In file included from include/linux/gfp.h:6:0,
>>>>                      from include/linux/mm.h:10,
>>>>                      from mm//swap.c:16:
>>>>>> include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>>>>      #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>>>           ^~~~~~~~~~~~~~~
>>>>
>>>> vim +/pageblock_order +1088 include/linux/mmzone.h
>>>>
>>>>    1087	
>>>>> 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>>>>    1089	#error Allocator pageblock_order exceeds SECTION_SIZE
>>>>    1090	#endif
>>>>    1091	
>>>>
>>> I took a look at the latest code, at line 1082 of the same file uses
>>> pageblock_order. And I apply this patch on top of v4.20-rc5, the build
>>> looks good to me.
>>>
>>> Confused why this introduce an compile error.
>> Hi Wei,
>>
>> we could reproduce the warnings with using make.cross.
>>
> That's interesting.
>
> Do you see this file already use pageblock_order in line 1081?
>
> Is this one report warning?
>

both questions is yes.

Best Regards,
Rong Chen



[-- Attachment #2: Type: text/html, Size: 4927 bytes --]

Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin

[Wei Yang]

On Thu, Dec 13, 2018 at 01:02:21PM +0800, Rong Chen wrote:
>
>
>On 12/13/2018 11:08 AM, Wei Yang wrote:
>> On Thu, Dec 13, 2018 at 10:26:41AM +0800, Rong Chen wrote:
>> > 
>> > On 12/09/2018 08:03 PM, Wei Yang wrote:
>> > > On Sat, Dec 08, 2018 at 09:42:29AM +0800, kbuild test robot wrote:
>> > > > Hi Wei,
>> > > > 
>> > > > Thank you for the patch! Perhaps something to improve:
>> > > > 
>> > > > [auto build test WARNING on linus/master]
>> > > > [also build test WARNING on v4.20-rc5 next-20181207]
>> > > > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>> > > > 
>> > > > url:    https://github.com/0day-ci/linux/commits/Wei-Yang/mm-pageblock-make-sure-pageblock-won-t-exceed-mem_sectioin/20181207-030601
>> > > > config: powerpc-allmodconfig (attached as .config)
>> > > > compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> > > > reproduce:
>> > > >          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> > > >          chmod +x ~/bin/make.cross
>> > > >          # save the attached .config to linux build tree
>> > > >          GCC_VERSION=7.2.0 make.cross ARCH=powerpc
>> > > > 
>> > > > All warnings (new ones prefixed by >>):
>> > > > 
>> > > >     In file included from include/linux/gfp.h:6:0,
>> > > >                      from include/linux/xarray.h:14,
>> > > >                      from include/linux/radix-tree.h:31,
>> > > >                      from include/linux/fs.h:15,
>> > > >                      from include/linux/compat.h:17,
>> > > >                      from arch/powerpc/kernel/asm-offsets.c:16:
>> > > > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>> > > >      #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> > > >           ^~~~~~~~~~~~~~~
>> > > > --
>> > > >     In file included from include/linux/gfp.h:6:0,
>> > > >                      from include/linux/mm.h:10,
>> > > >                      from mm//swap.c:16:
>> > > > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>> > > >      #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> > > >           ^~~~~~~~~~~~~~~
>> > > >     In file included from include/linux/gfp.h:6:0,
>> > > >                      from include/linux/mm.h:10,
>> > > >                      from mm//swap.c:16:
>> > > > > > include/linux/mmzone.h:1088:6: warning: "pageblock_order" is not defined, evaluates to 0 [-Wundef]
>> > > >      #if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> > > >           ^~~~~~~~~~~~~~~
>> > > > 
>> > > > vim +/pageblock_order +1088 include/linux/mmzone.h
>> > > > 
>> > > >    1087	
>> > > > > 1088	#if (pageblock_order + PAGE_SHIFT) > SECTION_SIZE_BITS
>> > > >    1089	#error Allocator pageblock_order exceeds SECTION_SIZE
>> > > >    1090	#endif
>> > > >    1091	
>> > > > 
>> > > I took a look at the latest code, at line 1082 of the same file uses
>> > > pageblock_order. And I apply this patch on top of v4.20-rc5, the build
>> > > looks good to me.
>> > > 
>> > > Confused why this introduce an compile error.
>> > Hi Wei,
>> > 
>> > we could reproduce the warnings with using make.cross.
>> > 
>> That's interesting.
>> 
>> Do you see this file already use pageblock_order in line 1081?
>> 
>> Is this one report warning?
>> 
>
>both questions is yes.
>

Sounds interesting :-)

I don't have a power machine and we may drop this patch as discussed, so
I won't look into this now.

Thanks for your effort.

>Best Regards,
>Rong Chen
>
>

-- 
Wei Yang
Help you, Help me