[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ddcb1d70-2e4b-a185-b749-d4f300feec18@redhat.com>
Date: Fri, 20 Nov 2020 10:31:05 +0100
From: David Hildenbrand <david@...hat.com>
To: Oscar Salvador <osalvador@...e.de>
Cc: mhocko@...nel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, vbabka@...e.cz, pasha.tatashin@...een.com
Subject: Re: [RFC PATCH 3/3] mm,memory_hotplug: Allocate memmap from the added
memory range
>>> - move_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_ISOLATE);
>>> + move_pfn_range_to_zone(zone, pfn, nr_pages, nr_vmemmap_pages, NULL,
>>> + MIGRATE_ISOLATE);
>>
>> As mentioned, I'd suggest properly initializing the memmap here
>>
>> if (nr_vmemmap_pages) {
>> move_pfn_range_to_zone(zone, pfn, nr_vmemmap_pages, NULL,
>> MIGRATE_UNMOVABLE);
>> }
>> move_pfn_range_to_zone(zone, valid_start_pfn, valid_nr_pages, NULL,
>
> Sure, agreed.
>
>>> + if (!support_memmap_on_memory(size))
>>> + mhp_flags &= ~MEMHP_MEMMAP_ON_MEMORY;
>>
>> Callers (e.g., virtio-mem) might rely on this. We should reject this with
>> -EINVAL and provide a way for callers to test whether this flag is possible.
>
> Uhm, we might want to make "support_memmap_on_memory" public, and
> callers who might want to it use can check its return value?
> Or do you have something else in mind?
Right, a way for callers to check if it's supported.
"mhp_supports_memmap_on_memory" or sth. like that.
Thanks!
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists