[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3b151ec-b050-d5bf-0cd1-d8489463c169@redhat.com>
Date: Wed, 3 Apr 2019 10:53:23 +0200
From: David Hildenbrand <david@...hat.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Oscar Salvador <osalvador@...e.de>, akpm@...ux-foundation.org,
dan.j.williams@...el.com, Jonathan.Cameron@...wei.com,
anshuman.khandual@....com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 0/4] mm,memory_hotplug: allocate memmap from hotadded
memory
On 03.04.19 10:49, Michal Hocko wrote:
> On Wed 03-04-19 10:41:35, David Hildenbrand wrote:
>> On 03.04.19 10:37, Michal Hocko wrote:
> [...]
>>> That being said it should be the caller of the hotplug code to tell
>>> the vmemmap allocation strategy. For starter, I would only pack vmemmaps
>>> for "regular" kernel zone memory. Movable zones should be more careful.
>>> We can always re-evaluate later when there is a strong demand for huge
>>> pages on movable zones but this is not the case now because those pages
>>> are not really movable in practice.
>>
>> Remains the issue with potential different user trying to remove memory
>> it didn't add in some other granularity. We then really have to identify
>> and isolate that case.
>
> Can you give an example of a sensible usecase that would require this?
>
The two cases I mentioned are
1. arch/powerpc/platforms/powernv/memtrace.c: memtrace_alloc_node()
AFAIKS, memory that wasn't added by memtrace is tried to be offlined +
removed.
"Remove memory in memory block size chunks so that iomem resources are
always split to the same size and we never try to remove memory that
spans two iomem resources"
2. drivers/acpi/acpi_memhotplug.c:acpi_memory_enable_device()
We might hit "__add_memory() == -EEXIST" and continue. When removing the
devices, __remove_memory() is called. I am still to find out if that
could imply removing in a different granularity than added.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists