On 29.05.25 09:46, Michal Hocko wrote:
On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
[...]
I think we just have to be careful to document it properly -- especially the
shortcomings and that this feature might become a problem in the future.
Movable user-space page tables getting placed on CMA memory would probably
not be a problem if we don't care about ... user-space data either way.
I think makedumpfile could refuse to capture a dump if userspace memory
is requested to enforce this.
Yeah, it will be tricky once we support placing other memory on CMA
regions. E.g., there was the discussion of making some slab allocations
movable.
But probably, in such a configuration, we would later simply refuse to
active CMA kdump.
The whole "Direct I/O takes max 1s" part is a bit shaky. Maybe it could be
configurable how long to wait? 10s is certainly "safer".
Quite honestly we will never know and rather than making this
configurable I would go with reasonably large. Couple of seconds
certainly do not matter for the kdump situations but I would go as far
as minutes.
I recall that somebody raised that kdump downtime might be problematic
(might affect service downtime?).
So I would just add a kconfig option with a default of 10s.
But even better if we can avoid the kconfig and just make it 10s for all
setups.
I would not suggest having a different (runtime/boottime) way of
configuring this.
--
Cheers,
David / dhildenb
