* [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 [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 [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 ` 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 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-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
* 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
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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox