* [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
@ 2018-12-05 9:19 Wei Yang
2018-12-05 9:19 ` [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set Wei Yang
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Wei Yang @ 2018-12-05 9:19 UTC (permalink / raw)
To: linux-mm; +Cc: mgorman, akpm, 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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set
2018-12-05 9:19 [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Wei Yang
@ 2018-12-05 9:19 ` Wei Yang
2018-12-07 9:58 ` Wei Yang
2018-12-05 11:15 ` [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Mel Gorman
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ messages in thread
From: Wei Yang @ 2018-12-05 9:19 UTC (permalink / raw)
To: linux-mm; +Cc: mgorman, akpm, 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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 9:19 [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Wei Yang
2018-12-05 9:19 ` [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set Wei Yang
@ 2018-12-05 11:15 ` Mel Gorman
2018-12-05 12:08 ` Wei Yang
2018-12-08 1:42 ` kbuild test robot
2018-12-09 13:58 ` kbuild test robot
3 siblings, 1 reply; 18+ messages in thread
From: Mel Gorman @ 2018-12-05 11:15 UTC (permalink / raw)
To: Wei Yang; +Cc: linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 11:15 ` [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Mel Gorman
@ 2018-12-05 12:08 ` Wei Yang
2018-12-05 15:37 ` Mel Gorman
0 siblings, 1 reply; 18+ messages in thread
From: Wei Yang @ 2018-12-05 12:08 UTC (permalink / raw)
To: Mel Gorman; +Cc: Wei Yang, linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 12:08 ` Wei Yang
@ 2018-12-05 15:37 ` Mel Gorman
2018-12-05 22:31 ` Wei Yang
0 siblings, 1 reply; 18+ messages in thread
From: Mel Gorman @ 2018-12-05 15:37 UTC (permalink / raw)
To: Wei Yang; +Cc: linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 15:37 ` Mel Gorman
@ 2018-12-05 22:31 ` Wei Yang
2018-12-06 9:00 ` David Hildenbrand
0 siblings, 1 reply; 18+ messages in thread
From: Wei Yang @ 2018-12-05 22:31 UTC (permalink / raw)
To: Mel Gorman; +Cc: Wei Yang, linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 22:31 ` Wei Yang
@ 2018-12-06 9:00 ` David Hildenbrand
2018-12-06 9:21 ` Wei Yang
0 siblings, 1 reply; 18+ messages in thread
From: David Hildenbrand @ 2018-12-06 9:00 UTC (permalink / raw)
To: Wei Yang, Mel Gorman; +Cc: linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-06 9:00 ` David Hildenbrand
@ 2018-12-06 9:21 ` Wei Yang
2018-12-06 9:26 ` David Hildenbrand
0 siblings, 1 reply; 18+ messages in thread
From: Wei Yang @ 2018-12-06 9:21 UTC (permalink / raw)
To: David Hildenbrand; +Cc: Wei Yang, Mel Gorman, linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-06 9:21 ` Wei Yang
@ 2018-12-06 9:26 ` David Hildenbrand
2018-12-06 9:42 ` Wei Yang
0 siblings, 1 reply; 18+ messages in thread
From: David Hildenbrand @ 2018-12-06 9:26 UTC (permalink / raw)
To: Wei Yang; +Cc: Mel Gorman, linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-06 9:26 ` David Hildenbrand
@ 2018-12-06 9:42 ` Wei Yang
0 siblings, 0 replies; 18+ messages in thread
From: Wei Yang @ 2018-12-06 9:42 UTC (permalink / raw)
To: David Hildenbrand; +Cc: Wei Yang, Mel Gorman, linux-mm, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set
2018-12-05 9:19 ` [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set Wei Yang
@ 2018-12-07 9:58 ` Wei Yang
0 siblings, 0 replies; 18+ messages in thread
From: Wei Yang @ 2018-12-07 9:58 UTC (permalink / raw)
To: Wei Yang; +Cc: linux-mm, mgorman, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 9:19 [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Wei Yang
2018-12-05 9:19 ` [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set Wei Yang
2018-12-05 11:15 ` [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Mel Gorman
@ 2018-12-08 1:42 ` kbuild test robot
2018-12-09 12:03 ` Wei Yang
2018-12-09 13:58 ` kbuild test robot
3 siblings, 1 reply; 18+ messages in thread
From: kbuild test robot @ 2018-12-08 1:42 UTC (permalink / raw)
To: Wei Yang; +Cc: kbuild-all, linux-mm, mgorman, akpm
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-08 1:42 ` kbuild test robot
@ 2018-12-09 12:03 ` Wei Yang
2018-12-13 2:26 ` Rong Chen
0 siblings, 1 reply; 18+ messages in thread
From: Wei Yang @ 2018-12-09 12:03 UTC (permalink / raw)
To: kbuild test robot; +Cc: Wei Yang, kbuild-all, linux-mm, mgorman, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-05 9:19 [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Wei Yang
` (2 preceding siblings ...)
2018-12-08 1:42 ` kbuild test robot
@ 2018-12-09 13:58 ` kbuild test robot
3 siblings, 0 replies; 18+ messages in thread
From: kbuild test robot @ 2018-12-09 13:58 UTC (permalink / raw)
To: Wei Yang; +Cc: kbuild-all, linux-mm, mgorman, akpm
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-09 12:03 ` Wei Yang
@ 2018-12-13 2:26 ` Rong Chen
2018-12-13 3:08 ` Wei Yang
0 siblings, 1 reply; 18+ messages in thread
From: Rong Chen @ 2018-12-13 2:26 UTC (permalink / raw)
To: Wei Yang, kbuild test robot; +Cc: kbuild-all, linux-mm, mgorman, akpm
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
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-13 2:26 ` Rong Chen
@ 2018-12-13 3:08 ` Wei Yang
2018-12-13 5:02 ` Rong Chen
0 siblings, 1 reply; 18+ messages in thread
From: Wei Yang @ 2018-12-13 3:08 UTC (permalink / raw)
To: Rong Chen
Cc: Wei Yang, kbuild test robot, kbuild-all, linux-mm, mgorman, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-13 3:08 ` Wei Yang
@ 2018-12-13 5:02 ` Rong Chen
2018-12-13 7:28 ` Wei Yang
0 siblings, 1 reply; 18+ messages in thread
From: Rong Chen @ 2018-12-13 5:02 UTC (permalink / raw)
To: Wei Yang; +Cc: kbuild test robot, kbuild-all, linux-mm, mgorman, akpm
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin
2018-12-13 5:02 ` Rong Chen
@ 2018-12-13 7:28 ` Wei Yang
0 siblings, 0 replies; 18+ messages in thread
From: Wei Yang @ 2018-12-13 7:28 UTC (permalink / raw)
To: Rong Chen
Cc: Wei Yang, kbuild test robot, kbuild-all, linux-mm, mgorman, akpm
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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2018-12-13 7:28 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-05 9:19 [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Wei Yang
2018-12-05 9:19 ` [PATCH 2/2] mm, page_alloc: cleanup usemap_size() when SPARSEMEM is not set Wei Yang
2018-12-07 9:58 ` Wei Yang
2018-12-05 11:15 ` [PATCH 1/2] mm, pageblock: make sure pageblock won't exceed mem_sectioin Mel Gorman
2018-12-05 12:08 ` Wei Yang
2018-12-05 15:37 ` Mel Gorman
2018-12-05 22:31 ` Wei Yang
2018-12-06 9:00 ` David Hildenbrand
2018-12-06 9:21 ` Wei Yang
2018-12-06 9:26 ` David Hildenbrand
2018-12-06 9:42 ` Wei Yang
2018-12-08 1:42 ` kbuild test robot
2018-12-09 12:03 ` Wei Yang
2018-12-13 2:26 ` Rong Chen
2018-12-13 3:08 ` Wei Yang
2018-12-13 5:02 ` Rong Chen
2018-12-13 7:28 ` Wei Yang
2018-12-09 13:58 ` kbuild test robot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.