lkml.org 
[lkml]   [2022]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v1 2/2] drivers/base/memory: determine and store zone for single-zone memory blocks
From
[...] having accidentally skipped two comments.


>
>> There are three scenarios to handle:
> ...
> ...
>
>> @@ -225,6 +226,9 @@ static int memory_block_offline(struct memory_block *mem)
>> unsigned long nr_vmemmap_pages = mem->nr_vmemmap_pages;
>> int ret;
>>
>> + if (!mem->zone)
>> + return -EBUSY;
>
> Should not we return -EINVAL? I mean, -EBUSY reads like this might be a
> temporary error which might get fixed later on, but that isn't the case.

We should, and I could have sworn I fixed that up last-minute.

>> +static struct zone *early_node_zone_for_memory_block(struct memory_block *mem,
>> + int nid)
>> +{
>> + const unsigned long start_pfn = section_nr_to_pfn(mem->start_section_nr);
>> + const unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
>> + struct zone *zone, *matching_zone = NULL;
>> + pg_data_t *pgdat = NODE_DATA(nid);
>
> I was about to complain because in init_memory_block() you call
> early_node_zone_for_memory_block() with nid == NUMA_NODE_NODE, but then
> I saw that NODE_DATA on !CONFIG_NUMA falls to contig_page_data.
> So, I guess we cannot really reach this on CONFIG_NUMA machines with nid
> being NUMA_NO_NODE, right? (do we want to add a check just in case?)
>
>> +#ifdef CONFIG_NUMA
>> +void memory_block_set_nid(struct memory_block *mem, int nid,
>> + enum meminit_context context)
>
> But we also set the zone? (Only for boot memory)

Yes, it's derived from the node internally, though, and not supplied
explicitly. Renaming it could be misleading IMHO.

--
Thanks,

David / dhildenb

\
 
 \ /
  Last update: 2022-01-31 12:52    [W:0.067 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site