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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
>> >
>> >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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux