On 22.10.19 10:20, Michal Hocko wrote:
On Mon 21-10-19 17:54:35, David Hildenbrand wrote:
On 21.10.19 17:47, Michal Hocko wrote:
On Mon 21-10-19 17:39:36, David Hildenbrand wrote:
On 21.10.19 16:43, Michal Hocko wrote:
[...]
We still set PageReserved before onlining pages and that one should be
good to go as well (memmap_init_zone).
Thanks!
memmap_init_zone() is called when onlining memory. There, set all pages to
reserved right now (on context == MEMMAP_HOTPLUG). We clear PG_reserved when
onlining a page to the buddy (e.g., generic_online_page). If we would online
a memory block with holes, we would want to keep all such pages
(!pfn_valid()) set to reserved. Also, there might be other side effects.
Isn't it sufficient to have those pages in a poisoned state? They are
not onlined so their state is basically undefined anyway. I do not see
how PageReserved makes this any better.
It is what people have been using for a long time. Memory hole ->
PG_reserved. The memmap is valid, but people want to tell "this here is
crap, don't look at it".
The page is poisoned, right? If yes then setting the reserved bit
doesn't make any sense.
No it's not poisoned AFAIK. It should be initialized - and I remember
that PG_reserved on memory holes is relevant to detect MMIO pages.
(e.g., looking at KVM code ...)
Also is the hole inside a hotplugable memory something we really have to
care about. Has anybody actually seen a platform to require that?
That's what I was asking. I can see "support" for this was added basically
right from the beginning. I'd say we rip that out and cleanup/simplify. I am
not aware of a platform that requires this. Especially, memory holes on
DIMMs (detected during boot) seem like an unlikely thing.
The thing is that the hotplug development shows ad-hoc decisions
throughout the code. It is even worse that it is hard to guess whether
some hludges are a result of a careful design or ad-hoc trial and
failure approach on setups that never were production. Building on top
of that be preserving hacks is not going to improve the situation. So I
am perfectly fine to focus on making the most straightforward setups
work reliably. Even when there is a risk of breaking some odd setups. We
can fix them up later but we would have at least a specific example and
document it.
Alright, I'll prepare a simple patch that rejects offlining memory with
memory holes. We can apply that and see if anybody screams out loud. If
not, we can clean up that crap.
--
Thanks,
David / dhildenb
