One issue usually is that often firmware can allocate from available
system RAM and/or modify/initialize it. I assume you're running some
custom firmware :)
We have a special firmware that does not touch the last 2G of physical
memory for its allocations :)
Personally, I think the future is 4k, especially for smaller machines.
(also, imagine right now how many 512MB THP you can actually use in your
8GB VM ..., simply not suitable for small machines).
Um, this is not really about 512THP. Yes, this is smaller machine, but
performance is very important to us. Boot budget for the kernel is
under half a second. With 64K we save 0.2s 0.35s vs 0.55s. This is
because fewer struct pages need to be initialized. Also, fewer TLB
misses, and 3-level page tables add up as performance benefits. >
For larger servers 64K pages make total sense: Less memory is wasted as metdata.
Right, but I do not think it is possible to do for dax devices (as of
right now). I assume, it contains information about what kind of
device it is: devdax, fsdax, sector, uuid etc.
See [1] namespaces tabel. It contains summary of pmem devices types,
and which of them have label (all except for raw).
Interesting, I wonder if the label is really required to get this
special use case running. I mean, all you want is to have dax/kmem
expose the whole thing as system RAM. You don't want to lose even 2MB if
it's just for the sake of unnecessary metadata - this is not a real
device, it's "fake" already.
Hm, would not it essentially mean allowing memory hot-plug for raw
pmem devices? Something like create mmap, and hot-add raw pmem?