Messages in this thread | | | Date | Mon, 31 Jan 2022 12:42:49 +0100 | Subject | Re: [PATCH v1 2/2] drivers/base/memory: determine and store zone for single-zone memory blocks | From | David Hildenbrand <> |
| |
[...] 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
| |