I'm highly confident that I use preallocated hugetlb pages and I have most of ram free on 64GB system. The problem appears only with: CONFIG_PREEMPT=y
$ cat /proc/sys/vm/nr_hugepages 8192 $ cat /proc/meminfo .. HugePages_Total: 8192 HugePages_Free: 0 $ mount |grep huge hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) # Allow realtime tasks to monopolize CPU echo -1 > /proc/sys/kernel/sched_rt_runtime_us qemu realtime priority: chrt -r 5 /usr/bin/qemu-system-x86_64 -overcommit mem-lock=on -mem-path /dev/hugepages/qemu-mem [allow use 10 of 16 cpu threads] i9900ks + rtx 2080ti + 64GB ram On Wed, Nov 23, 2022 at 2:42 AM Alex Williamson <alex.william...@redhat.com> wrote: > > On Tue, 22 Nov 2022 17:57:37 +1100 > Ivan Volosyuk <ivan.volos...@gmail.com> wrote: > > > Is there something special about the pinning step? When I start a new > > VM with 16G in dedicated hugepages my system becomes quite > > unresponsive for several seconds, significant packet loss and random > > hang device oopses if I use preemptive kernel? > > Pinning in blocking in the ioctl, but this should only affect the QEMU > process, not other host tasks, there are various schedule calls to > prevent this. A 16GB, hugepage VM certainly shouldn't cause such > problems. Are you sure the VM is really using pre-allocated hugepages? > This sounds more like a host system that's being forced to swap to > accommodate the VM page pinning. Thanks, > > Alex > _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://listman.redhat.com/mailman/listinfo/vfio-users
