Messages in this thread | | | Date | Wed, 26 Jul 2023 10:31:02 +0200 | From | David Hildenbrand <> | Subject | Re: collision between ZONE_MOVABLE and memblock allocations |
| |
>> As an alternative, we might use the "memmap=nn[KMG]!ss[KMG]" [1] parameter >> to mark some memory as protected. >> >> That memory can then be configured as devdax device and online to >> ZONE_MOVABLE (dev/dax). >> >> [1] https://docs.pmem.io/persistent-memory/getting-started-guide/creating-development-environments/linux-environments/linux-memmap > > I've previously been reconfiguring devdax memory like this: > > ndctl create-namespace --reconfig=namespace0.0 -m devdax -f > daxctl reconfigure-device --mode=system-ram dax0.0 > > Is this how you've been doing it, or is there something else I should > consider?
No, exactly like that.
> > I just sent mail to Michal outlining my use case, hopefully it makes sense.
Yes, thanks for sharing, I'll dig deeper into that next.
> > I had thought about using 'memmap=' in the first kernel and the worry was that > I'd have to support many different machines with different memory > configurations, and have to hard-code memory offsets and lengths for the > various memmap= kernel command line parameters.
Indeed.
> If I can make ZONE_MOVABLE > work that's preferable because the kernel will choose the correct usermem-only > region for me, and then I can just use that region for the crash kernel and > 3rd kernel boots.
It really sounds like you might be better off using CMA or alloc_contig_pages().
The latter is unreliable, though, and the memory cannot be used for other purposes once alloc_contig_pages() succeeded
See arch/powerpc/platforms/powernv/memtrace.c one one user that needs to set aside a lot of memory to store HW traces.
-- Cheers,
David / dhildenb
| |