>>> Alternately, init_page_poison could do this cond_resched(), but it seems
>>> to me that the caller of init_page_poison() is what actually knows
>>> whether or not it should relax its own priority.
>>>
>>> Based on Dan's notes, I think this is perfectly safe:
>>> commit f931ab479dd2 ("mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}")
>>
>> We shouldn't be holding any spin locks, so it's safe. (we could think
>> about doing this outside of the memory hotplug lock in the case of
>> devmem, however, it's only a debugging feature so we most probably don't
>> care).
>>
>>>
>>> Aside from fixing the lockup, it is also a friendlier thing to do on
>>> lower core systems that might wipe out large chunks of hotplug memory
>>> (probably not a very common case).
>>
>> It really only is an issue for devmem. Ordinary hotplugged system memory
>> is not affected (onlined/offlined in memory block granularity).
>
> Could you explain this a bit? I was fixing the issue found on PMEM systems, but
> it seems like regularly memory hotplug was potentially a victim. I think one of
> the reasons PMEM might be more likely is the time it takes to work with any data
> structures store in the PMEM itself is slower (just a guess).
For system RAM, we have have (except one ppc exception):
memory_block_action()->offline_pages()->remove_pfn_range_from_zone()
Memory blocks span 1..X sections, usually only one. On x86-64, a memory
block is therefore 128MB..2G. Not a sufficiently large memmap to
actually trigger this - in contrast to ZONE_DEVICE regions.
--
Thanks,
David / dhildenb
