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 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.

-- 
Mel Gorman
SUSE Labs




[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