lkml.org 
[lkml]   [2021]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout
From
Date
On 12.02.21 11:11, Michal Hocko wrote:
> On Fri 12-02-21 10:56:19, David Hildenbrand wrote:
>> On 12.02.21 10:55, David Hildenbrand wrote:
>>> On 08.02.21 12:08, Mike Rapoport wrote:
> [...]
>>>> @@ -6519,8 +6581,19 @@ void __init get_pfn_range_for_nid(unsigned int nid,
>>>> *end_pfn = max(*end_pfn, this_end_pfn);
>>>> }
>>>> - if (*start_pfn == -1UL)
>>>> + if (*start_pfn == -1UL) {
>>>> *start_pfn = 0;
>>>> + return;
>>>> + }
>>>> +
>>>> +#ifdef CONFIG_SPARSEMEM
>>>> + /*
>>>> + * Sections in the memory map may not match actual populated
>>>> + * memory, extend the node span to cover the entire section.
>>>> + */
>>>> + *start_pfn = round_down(*start_pfn, PAGES_PER_SECTION);
>>>> + *end_pfn = round_up(*end_pfn, PAGES_PER_SECTION);
>>>
>>> Does that mean that we might create overlapping zones when one node
>>
>> s/overlapping zones/overlapping nodes/
>
> I didn't get to review the patch yet. Just wanted to note that we can
> interleave nodes/zone. Or what kind of concern do you have in mind?

I know that we can have it after boot, when hotplugging memory. How
about during boot?

For example, which node will a PFN then actually be assigned to?

I was just wondering if this might result in issues - if that can
already happen, then it's just fine I guess.

--
Thanks,

David / dhildenb

\
 
 \ /
  Last update: 2021-02-12 11:21    [W:0.134 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site