At start, I was at ~15gb and nothing in swap. After QEMU it's this and I got lag because of the swapping. Why. Process managers don't show me any process using this much.

At start, I was at ~15gb and nothing in swap. After QEMU it's this and I got lag because of the swapping. Why. Process managers don't show me any process using this much.

At start, I was at ~15gb and nothing in swap. After QEMU it's this and I got lag because of the swapping. Why. Process managers don't show me any process using this much.

At start, I was at ~15gb and nothing in swap. After QEMU it's this and I got lag because of the swapping. Why. Process managers don't show me any process using this much.

@volpeon@icy.wyvern.rip my native win 11 work laptop uses 32+gb ram. When I manually count using task manager I can't even reach half of that.

So I'd say, Windows is the reason.

@kura But how would Windows even be able to go beyond the 32gb RAM I allocated? 32gb is immediately gone, but there's about 20gb that gets used on top of that and it only returns long after I stopped QEMU.

@volpeon strange! is ballooning set on the VM? How much RAM did you allocate to it?

@anthropy I allocated 32gb. I'm not sure about ballooning, but here's the command I use:

taskset -c ${CPU_CORE} qemu-system-x86_64 \
   -name "Windows 10" \
   -machine q35,mem-merge=off,vmport=off \
   -accel kvm \
   -accel kvm,kernel-irqchip=on \
   -cpu host,+topoext,kvm=off,hv_spinlocks=0x1fff,hv_relaxed,hv_vapic,hv_time,hv_crash,hv_reset,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_vendor_id=Gigabyte \
   -smp 12,sockets=1,cores=6,threads=2 \
   -global ICH9-LPC.disable_s3=1 \
   -global ICH9-LPC.disable_s4=1 \
   -m ${RAM_SIZE} \
   -mem-prealloc \
   -rtc clock=host,base=localtime,driftfix=slew \
   -global kvm-pit.lost_tick_policy=delay \
   -overcommit mem-lock=off \
   -global kvm-pit.lost_tick_policy=discard \
   -nographic \
   -vga none \
   -serial none \
   -parallel none \
   -k en-us \
   -msg timestamp=on \
   -spice port=${SPICE_PORT},disable-ticketing=on \
   -usb \
   -audio driver=pipewire,model=hda,id=snd1 \
   -device ioh3420,chassis=1,bus=pcie.0,addr=03.0,id=ioh3420-root-port-1 \
   -device ivshmem-plain,memdev=ivshmem,bus=pcie.0 \
   -object memory-backend-file,id=ivshmem,share=on,mem-path=/dev/shm/looking-glass,size=128M \
   -chardev socket,id=chrtpm,path=/var/run/emulated_tpm/swtpm-sock \
   -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 \
   -object iothread,id=iothread0 \
   -netdev bridge,id=virbr0 \
   -device virtio-net-pci,netdev=virbr0,id=nic1 \
   -object input-linux,id=kbd1,evdev=${EV_KBD},grab_all=on,repeat=on,grab-toggle=alt-alt \
   -object input-linux,id=mouse1,evdev=${EV_MOUSE} \
   -device virtio-mouse-pci \
   -device virtio-keyboard-pci \
   -device vfio-pci,host=${VGA_ADDR},bus=ioh3420-root-port-1,addr=00.0,x-pci-sub-device-id=${VGA_SSID},x-pci-sub-vendor-id=${VGA_SVID},multifunction=on,x-vga=on \
   -drive file=${KVM_CODE},if=pflash,format=raw,unit=0,readonly=on \
   -drive file=${KVM_VARS},if=pflash,format=raw,unit=1 \
   -device virtio-scsi-pci,iothread=iothread0,num_queues=8,id=scsi \
   -drive file="${KVM_DISK}",index=0,media=disk,format=raw,if=none,aio=native,cache.direct=on,id=disk \
   -drive file="${KVM_DISK_2}",index=1,media=disk,format=raw,if=none,aio=native,cache.direct=on,id=disk2 \
   -device scsi-hd,drive=disk \
   -device scsi-hd,drive=disk2 \
   -drive file="${KVM_OPTI}",index=1,media=cdrom \
   -drive file="${KVM_CDRV}",index=2,media=cdrom \
   -device usb-tablet ${USB_DEVS} \
   -boot menu=on \
   -chardev stdio,mux=on,id=monitor-0 \
   -mon chardev=monitor-0 \
   -chardev socket,id=char0,path=/tmp/vhostqemu \
   -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=Host \
   -object memory-backend-memfd,id=vfsmem,size=${RAM_SIZE},share=on \
   -numa node,memdev=vfsmem

@anthropy I really need to clean this thing up. It grew over the years. ​​

@volpeon hah it definitely is a sizable command, but that's how that stuff always goes x3 I also see some legacy things that could be skipped or replaced.

I see you're telling QEMU twice how memory to use in different ways, I don't know 100% sure if that could cause issues, but you could consider either removing the -m or the `-object memory-backend-memfd` and `-numa` bit, I'd recommend only using -m, unless you specifically want to specify the memory and cpu architecture in non-standard ways.

@volpeon hah it definitely is a sizable command, but that's how that stuff always goes x3 I also see some legacy things that could be skipped or replaced.

I see you're telling QEMU twice how memory to use in different ways, I don't know 100% sure if that could cause issues, but you could consider either removing the -m or the `-object memory-backend-memfd` and `-numa` bit, I'd recommend only using -m, unless you specifically want to specify the memory and cpu architecture in non-standard ways.