mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-10 05:17:59 +03:00
qemu: Don't prealloc mem for real NVDIMMs
Currently, we configure QEMU to prealloc memory almost by default. Well, by default for NVDIMMs, hugepages and if user asked us to (via memoryBacking <allocation mode="immediate"/>). However, when guest's NVDIMM is backed by real life NVDIMM this approach is not the best. In this case users should put <pmem/> into the <memory/> device <source/>, like this: <memory model='nvdimm' access='shared'> <source> <path>/dev/pmem0</path> <pmem/> </source> </memory> Instructing QEMU to do prealloc in this case means that each page of the NVDIMM is "touched" (the first byte is read and written back - see QEMU commit v2.9.0-rc1~26^2) which cripples device wear. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1894053 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This commit is contained in:
parent
b304207f58
commit
bf14a9be1e
@ -3085,7 +3085,10 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps,
|
||||
|
||||
if (mem->nvdimmPath) {
|
||||
memPath = g_strdup(mem->nvdimmPath);
|
||||
prealloc = true;
|
||||
/* If the NVDIMM is a real device then there's nothing to prealloc.
|
||||
* If anything, we would be only wearing off the device. */
|
||||
if (!mem->nvdimmPmem)
|
||||
prealloc = true;
|
||||
} else if (useHugepage) {
|
||||
if (qemuGetDomainHupageMemPath(priv->driver, def, pagesize, &memPath) < 0)
|
||||
return -1;
|
||||
|
@ -20,7 +20,7 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \
|
||||
-object memory-backend-ram,id=ram-node0,size=224395264 \
|
||||
-numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \
|
||||
-object memory-backend-file,id=memnvdimm0,mem-path=/tmp/nvdimm,share=no,\
|
||||
prealloc=yes,size=536870912,pmem=yes \
|
||||
size=536870912,pmem=yes \
|
||||
-device nvdimm,node=0,memdev=memnvdimm0,id=nvdimm0,slot=0 \
|
||||
-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
|
||||
-display none \
|
||||
|
Loading…
Reference in New Issue
Block a user