On 2017/12/6 8:58, Andrew Morton wrote:
> On Mon, 4 Dec 2017 21:48:04 +0800 zhong jiang <zhongjiang@xxxxxxxxxx> wrote:
>
>> Currently, init_pages_in_zone walk the zone in pageblock_nr_pages
>> steps. MAX_ORDER_NR_PAGES is possible to have holes when
>> CONFIG_HOLES_IN_ZONE is set. it is likely to be different between
>> MAX_ORDER_NR_PAGES and pageblock_nr_pages. if we skip the size of
>> MAX_ORDER_NR_PAGES, it will result in the second 2M memroy leak.
>>
>> meanwhile, the change will make the code consistent. because the
>> entire function is based on the pageblock_nr_pages steps.
>>
>> ...
>>
>> --- a/mm/page_owner.c
>> +++ b/mm/page_owner.c
>> @@ -527,7 +527,7 @@ static void init_pages_in_zone(pg_data_t *pgdat, struct zone *zone)
>> */
>> for (; pfn < end_pfn; ) {
>> if (!pfn_valid(pfn)) {
>> - pfn = ALIGN(pfn + 1, MAX_ORDER_NR_PAGES);
>> + pfn = ALIGN(pfn + 1, pageblock_nr_pages);
>> continue;
>> }
> I *think* Michal and Vlastimil will be OK with this as-newly-presented.
> Guys, can you please have another think?
According to Vlastimil's comment, it is not simple as it looks to cover all corners.
Maybe architecture need explicit define the hole granularity to use correctly.
so far, I have no a good idea to solve it perfectly.
Anyway. I will go further to find out.
Thanks
zhong jiang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
